From owner-dnssec-trac at kirei.se Mon Jan 4 02:17:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 02:17:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.61a562ddfb19702719cce4d9c23f9eda@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by lijia@?): may be no, signer told me no new signature created. And I removed the step of audit from python code, so auditor should not matter. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 08:45:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 08:45:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.e3316a91f54d20740c40e695f9252303@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by rb): The signatures in your zone will expire, since your re-sign period is greater than the validity period. But you should get new signature each time the signer runs. I will have a look and see if I can recreate your problem. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 10:24:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 10:24:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.3a36c2b4662e52810f868f764a9b4d36@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by rb): Ohh, sorry. You have seconds and not minutes for the resign and refresh. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 10:31:56 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 10:31:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.934350c0ec39eff54f44afcfe1c93409@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by alex): Could you please post the relevant snippets of the logs? Could you please also provide a detailed directory listing of the /path/to/opendnssec/tmp/ folder (the Signer's WorkingDirectory in the conf.xml)? Also, could you please confirm which version of OpenDNSSEC you are using? When you say "And I removed the step of audit from python code, so auditor should not matter. ", do you mean that you removed the tag from the kasp.xml file? If you have changed the code, have you made any other changes to the code? Thanks, Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 10:41:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 10:41:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.a3599ac376d15dd6eadd8c83ac2b82ee@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by rb): Since == you will have cases where signatures are reused, but will expire before the next re-sign. should be greater than . (A signature will be refreshed when it has x seconds until expiration) http://trac.opendnssec.org/wiki/Signer/Using/Configuration/kasp If all of the signatures can be reused, then no new signatures will be created. This will be the case for the first 4.5 minutes. But can happen more over time depending on if all of the signatures will expire around the same time. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 12:50:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 12:50:07 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.fdd70624f5205b1a746aef62944c18f6@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by lijia@?): Replying to [comment:6 rb]: > Since == you will have cases where signatures are reused, but will expire before the next re-sign. should be greater than . > > (A signature will be refreshed when it has x seconds until expiration) > http://trac.opendnssec.org/wiki/Signer/Using/Configuration/kasp > > If all of the signatures can be reused, then no new signatures will be created. This will be the case for the first 4.5 minutes. But can happen more over time depending on if all of the signatures will expire around the same time. I do not quit understand the purpose of refresh. Do you mean that rrsig will recreate at the time (expiration_time - refresh)? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 4 13:41:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 13:41:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.f3217c7aef975666d6dfb159315aa3a1@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by rb): Correct. is the refresh interval, detailing when a signature should be refreshed. As signatures are typically valid for much longer than the interval between runs of the signer, there is no need to re- generate the signatures each time the signer is run if there is no change to the data being signed. The signature will be refreshed when the time until the signature expiration is closer than the refresh interval. I have updated the documentation to reflect this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Jan 4 15:31:47 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 4 Jan 2010 16:31:47 +0100 Subject: [Opendnssec-develop] Re: 28-29 January Planning of v1.1 and v2 In-Reply-To: <983F17705339E24699AA251B458249B51F197DE754@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B51F197DE754@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B51F197DEF76@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I am now requesting topics from you. Then I will write an agenda based > on your topics and what I have in mind. A draft agenda is now available on the wiki: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-01-28-29 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0IJ4+CjgaNTdVjaAQh7eQf/anP5MD1IJCpdXRNLNFDSQBwP5JVmnQd4 T+PkSTsJBuUnh6l/MLA+5ylxjOlq6eknmc21MUzLsRxHmf+dVyE2AnsMeqpgVBJU /tlc+Lp5gibsiGKLmHoqs86W87pzcNPASnz7PWiVmLdjqAeFNg0kSGnUzDTEn25l 9IN9sdbxtzDiTkg8usdOGtW5tofsEmolnIlB6YezIXjCxwypSihZ7jN+WtlYgZGb Vy3CcKGDWiAMnpYN0h4l2SbHci5xooNmSuQWq4UNuNMzLCVGaMp+THcGwSN5O+x0 vMkechU3R+VUliKb9j2K0Isbxc4k3ZB/RgA4DPvScr6ln6T+nzqr8w== =RqIS -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Jan 4 15:43:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 04 Jan 2010 15:43:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.5c9f39f14fcb4d3d3f4d473e8df3aa21@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by rb): I cannot recreate your problem. Was it releated to problem when the is not smaller than in your case? And that signatures are reused? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 02:41:51 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 02:41:51 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.feefe223a33e3c7adf96de918753fbca@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: resign, expire ---------------------------+------------------------------------------------ Comment(by lijia@?): Eh...I can't recreate this problem too. Today I rebuild the code(version rc2), change refresh let it different than resign, everything goes well, each time signer runs, it create several new rrsig. Then I roll refresh back to its previous value, signer runs well too. So maybe it's all my fault did something not right. Sorry for bothering you. New Year's disturbance. BTW, will signer support ixfr? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 08:50:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 08:50:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #68: validity period passed, but no new signatures created In-Reply-To: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> References: <052.bb5f1d8d969be02a597982fec6d9b6b9@kirei.se> Message-ID: <061.bc3b2fcbb7e2a8ac9b25a34e6b589b76@kirei.se> #68: validity period passed, but no new signatures created ---------------------------+------------------------------------------------ Reporter: lijia@? | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: trunk | Resolution: invalid Keywords: resign, expire | ---------------------------+------------------------------------------------ Changes (by matthijs): * status: new => closed * resolution: => invalid Comment: Replying to [comment:10 lijia@?]: > Eh...I can't recreate this problem too. Today I rebuild the code(version rc2), change refresh let it different than resign, everything goes well, each time signer runs, it create several new rrsig. > > Then I roll refresh back to its previous value, signer runs well too. > > So maybe it's all my fault did something not right. Sorry for bothering you. New Year's disturbance. Closing this report in that case. > > BTW, will signer support ixfr? There are plans to add IXFR support -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 08:55:46 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 08:55:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #65: -k option for ksk-roll not working In-Reply-To: <058.81a2a69a4b79eedb25e39fa768d25ab5@kirei.se> References: <058.81a2a69a4b79eedb25e39fa768d25ab5@kirei.se> Message-ID: <067.f01be84c67fd078cad300a771cb73d48@kirei.se> #65: -k option for ksk-roll not working ---------------------------------+------------------------------------------ Reporter: andyh@? | Owner: sion Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by rb): * status: assigned => closed * resolution: => fixed Comment: You should use the -x option for the keytag. -k is for the CKA_ID. And the problem was that you could not only use the -k option. Fixed in r2664. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 08:57:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 08:57:45 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #60: Auditor croaks on APL RR In-Reply-To: <055.cdacd4792d5103ba08c4c9d96ce61184@kirei.se> References: <055.cdacd4792d5103ba08c4c9d96ce61184@kirei.se> Message-ID: <064.856d04232bced1f026e8959854ed5b4f@kirei.se> #60: Auditor croaks on APL RR ------------------------------+--------------------------------------------- Reporter: olaf@? | Owner: alex Type: defect | Status: closed Priority: major | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 10:00:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 10:00:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) Message-ID: <061.b91b466378c352603e347ab80651e414@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Hello all and good year... 2010 and the "stable" Opendnssec(?) I has will many tests Opendnssec and DLV (by "dlv.isc.org"),but I think opendnssec is 100% NSEC 3 and not "dlv.isc.org". Are you testing this DLV, please (?). My error reporting : This zone currently has no DNSKEY records, and is not published in the ISC DLV Registry Damage... Best regards -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 10:34:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 10:34:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.986667e2aba3f333805e1053a94bcf99@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Comment(by rb): Hello Yeah, OpenDNSSEC is now considered stable. Could you give some background information? Are trying to upload DNSKEYs from your zone to dlv.isc.org? Do you have DNSKEYs in your zone if you check your signed zone? Use: dig yourzone.com DNSKEY Do you follow their instructions to have extra TXT RR? https://dlv.isc.org/about/requirements They support RSASHA1, DSA, NSEC3-RSASHA1-SHA1, and NSEC3-DSA-SHA1. But we also handles RSASHA256 and RSASHA512 So both dlv.isc.org and OpenDNSSEC handles NSEC3. As long as you can sign your zone, there is no problem with OpenDNSSEC. DLV is something that is handled by the resolver and in your case dlv.isc.org. Are you using a TLD that is not using DNSSEC? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 16:03:52 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 16:03:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.8801798d72fbbb53198fabf620f09934@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Comment(by archi.laurent@?>): Thanks a lot for this, i has read all ( i think and it's very short), and same my Bind has modified for DLV. I think DLV do not understand my "opendnsssec" signed zone (?), because i has too many errors : Line 2 has bad type: SOA (<-- perhaps the serial in unixtime) Line 3 has bad type: NS Line 4 has bad type: NS Line 5 has bad type: RRSIG Line 6 has bad type: RRSIG Line 11 has bad type: RRSIG Line 12 has bad type: NSEC3PARAM Line 13 has bad type: RRSIG Line 14 has bad type: NSEC3 Line 15 has bad type: RRSIG Line 16 has bad type: TXT Line 17 has bad type: TXT Line 18 has bad type: RRSIG Line 19 has bad type: NSEC3 Line 20 has bad type: RRSIG Line 21 has bad type: NS Line 22 has bad type: NS Line 27 has bad type: RRSIG Line 28 has bad type: NSEC3 Line 29 has bad type: RRSIG best regards -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 20:36:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 20:36:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.6b7baeedd43ae9f97d71b5a0e2d2e6e1@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Comment(by rb): Thank you for the copy of your zone. I do not want to be rude, but do you know how DNS works? Your domain name is archi.amt, but there is no TLD named amt. You could have this locally, but not available globally. ISC's DLV cannot find your zone since it is local. So you cannot use ISC's DLV for your zone. Do you want to be able to verify your zone locally? Then just configure your DNSKEY in your local resolver. Secondly, there are DNSKEYs and RRSIGs in the zone file, but it is not the file that is output from OpenDNSSEC. I know this by the fact that the zone file is not flattened. What have you done? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 5 20:46:46 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 05 Jan 2010 20:46:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.7c965c05cc4c2110706086ab592d8d06@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Comment(by rb): Why have you copied the DNSKEY+RRSIG and NSEC3+RRSIG back to your original zone file? If you are doing this then you have forgotten to copy the other RRSIGs which belong to the other RRs. This is how it should look like: Unsigned zone file -> OpenDNSSEC -> Signed zone file (a new file created by OpenDNSSEC) -> BIND (or whatever nameserver you are using) No need to copy anything. OpenDNSSEC will create the signed zone file which you load into BIND (this is done automatically if you have in conf.xml). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 6 09:44:22 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 06 Jan 2010 09:44:22 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #70: Auditor complains about wildcard Message-ID: <058.1bc28827a195414365fd8410c579bacd@kirei.se> #70: Auditor complains about wildcard ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: alex Type: defect | Status: new Priority: trivial | Component: Auditor Version: | Keywords: wildcard auditor escape ---------------------------------+------------------------------------------ Hello, I found a curious few reports in the message log, spewn out by the auditor: Jan 6 10:50:33 dhcp-45 ods-auditor[30074]: non-DNSSEC RRSet TXT included in Output that was not present in Input : *.vanrein.org. 3600 IN TXT "v=spf1 -all" Jan 6 10:50:33 dhcp-45 ods-auditor[30074]: Output zone does not contain non-DNSSEC RRSet : TXT, *42.vanrein.org. 3600 IN TXT "v=spf1 -all" Aside from being the answer to the most difficult question in the world, 42 is also the hexcode of * so this looks like something maps wrongly somewhere. The auditor ends with Jan 6 10:50:34 dhcp-45 ods-signerd: Auditor result: 3 which may or may not indicate an error; I did not find documentation on how to infer if the auditor is happy. The input line leading to this was escaped, \042 3600 IN TXT "v=spf1 -all" I suspect a cmdline tool like dig must have inserted it during an AXFR, and it is accepted by NSD, so I am assuming this is proper formatting. If not, this is not a bug report at all :) but otherwise it is one. Anyway, a simple work-around exists which is hereby documented: After I changed \042 to * it all worked nicely. Cheers, -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 6 10:38:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 06 Jan 2010 10:38:27 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #70: Auditor complains about wildcard In-Reply-To: <058.1bc28827a195414365fd8410c579bacd@kirei.se> References: <058.1bc28827a195414365fd8410c579bacd@kirei.se> Message-ID: <067.8885201d72167174fe2674c5989edad5@kirei.se> #70: Auditor complains about wildcard ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: alex Type: defect | Status: new Priority: trivial | Component: Auditor Version: | Keywords: wildcard auditor escape ---------------------------------+------------------------------------------ Comment(by rick@?): The following appears to be a similar error in the Auditor's parser: Jan 6 11:57:33 dhcp-45 ods-auditor[32397]: non-DNSSEC RRSet CNAME included in Output that was not present in Input : www.0cpm.net. 86400 IN CNAME 0cpm.net Jan 6 11:57:33 dhcp-45 ods-auditor[32397]: Output zone does not contain non-DNSSEC RRSet : CNAME, www.0cpm.net. 86400 IN CNAME \@.0cpm.net This too may be contributed to non-standard notation that is at least processed by the NLnet Labs parser but not by dnsruby; the source file contains a somewhat funny resource record text "IN CNAME @". Again, substituting the domain worked around this issue. -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 6 10:44:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 06 Jan 2010 10:44:41 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #71: Auditor blocks domain signing entirely Message-ID: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> #71: Auditor blocks domain signing entirely ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: | Keywords: auditor deadlock ---------------------------------+------------------------------------------ With the previously reported problems, I found the auditor blocking signing of domains entirely. It was not until I had repaired them, and restarted ods-control, that additional domains were handled. Until that point, all the later-added domains were deadlocked. Now this is startling. Does it mean that the Auditor does not block a single erroneous domain from being signed, but actually stop the entire OpenDNSSEC project? Does that not make the entire infrastructure quite brittle and unreliable? Cheers, -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 6 10:49:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 06 Jan 2010 10:49:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> Message-ID: <067.6fdb36447051b710dc6e1666d5051ffe@kirei.se> #71: Auditor blocks domain signing entirely ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: matthijs Type: defect | Status: assigned Priority: critical | Component: Signer Version: | Keywords: auditor deadlock ---------------------------------+------------------------------------------ Changes (by alex): * owner: alex => matthijs * status: new => assigned * component: Auditor => Signer Comment: The Signer starts the auditor each time a zone is to be audited (after it has been signed). The signer either publishes the file or not, depending on the result of the auditor. The auditor is unable to "block" the publishing of other domains. I'm not sure what the signer logic is when one zone has failed an audit. I would have presumed that it would carry on and sign the other zones (and I think I have seen this happen on my machine). Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 6 11:32:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 06 Jan 2010 11:32:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> Message-ID: <067.07dd9bf493d3b0b0011cf8c33be11336@kirei.se> #71: Auditor blocks domain signing entirely ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: matthijs Type: defect | Status: assigned Priority: critical | Component: Signer Version: | Keywords: auditor deadlock ---------------------------------+------------------------------------------ Comment(by matthijs): Works for me: I let one zone constantly fail, the others end up in the signed directory -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at openfortress.nl Wed Jan 6 12:48:45 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 6 Jan 2010 12:48:45 +0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <067.07dd9bf493d3b0b0011cf8c33be11336@kirei.se> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> <067.07dd9bf493d3b0b0011cf8c33be11336@kirei.se> Message-ID: <20100106124845.GB4461@phantom.vanrein.org> Hi, > Works for me: > > I let one zone constantly fail, the others end up in the signed directory Are you talking about freshly added domains, or previously existing ones? I'm trying to think what was different in my case. Could the following perhaps be an explanation? I may have been adding more domains than I had keys ready. (Not sure how that works exactly, we only have howto documentation online.) A zone was signed with the last keys available. It had a problem and so failed to pass through to the signed state. The lack of further keys blocked the additional domains until more keys were made available. If that sort of thing can happen, it's an understandable explanation to me. Otherwise, I might try adding yet another bunch of domains, with a "IN CNAME @" record in the first. Thanks, -Rick From matthijs at NLnetLabs.nl Wed Jan 6 13:06:04 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 06 Jan 2010 14:06:04 +0100 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <20100106124845.GB4461@phantom.vanrein.org> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> <067.07dd9bf493d3b0b0011cf8c33be11336@kirei.se> <20100106124845.GB4461@phantom.vanrein.org> Message-ID: <4B448ABC.8030806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rick, Rick van Rein wrote: > Hi, > >> Works for me: >> >> I let one zone constantly fail, the others end up in the signed directory > > Are you talking about freshly added domains, or previously existing ones? I started from scratch. I did not try to add new domains later on. > I'm trying to think what was different in my case. Could the following > perhaps be an explanation? > > I may have been adding more domains than I had keys ready. (Not sure how > that works exactly, we only have howto documentation online.) > > A zone was signed with the last keys available. It had a problem and so > failed to pass through to the signed state. > > The lack of further keys blocked the additional domains until more keys > were made available. Could be. Doesn't the log say why zones failed signing? Could you provide the logs? > If that sort of thing can happen, it's an understandable explanation > to me. Otherwise, I might try adding yet another bunch of domains, with > a "IN CNAME @" record in the first. I don't think you can have an @ at the right side of a CNAME, correct me if I'm wrong. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLRIq6AAoJEA8yVCPsQCW5gsIH/iErD4z9vUIk1tpiK1DCKE1l E8RvoAq45vzxX5hCy1ZGIcZ/TsSofuKWvJcc2znU+fFAbP28E4wwEz0Xie9hKYrz ZpXQy/OP9tNuMXWa3NtaaNucddyqF6+6hlCzvfqXNBsa/5l2SQD94TKhHU2UIzHR PKxZWPzzpuKh2jQbgBPz3SmNWyyP0szulJJi72ejefZUv7FARaAxIYgltzT6zEpM QdXCdWZm/qiKdHnTKr5xJXFrJfU3tlWsUN77v9cSVj6umYCy/wT2m0SQValuXA1Z cr/STGcMjBmv7CnTl0ClhiadgNO1PuEFNKLDPxDBN4oThfweqX1Ms3aAhw/yuJU= =C0gy -----END PGP SIGNATURE----- From Ray.Bellis at nominet.org.uk Wed Jan 6 14:06:58 2010 From: Ray.Bellis at nominet.org.uk (Ray.Bellis at nominet.org.uk) Date: Wed, 6 Jan 2010 14:06:58 +0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <4B448ABC.8030806@nlnetlabs.nl> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> <067.07dd9bf493d3b0b0011cf8c33be11336@kirei.se> <20100106124845.GB4461@phantom.vanrein.org> <4B448ABC.8030806@nlnetlabs.nl> Message-ID: > I don't think you can have an @ at the right side of a CNAME, correct me > if I'm wrong. I don't know of any reason why not. It should just expand to $ORIGIN, just like any other use of it. In fact there's no other way to create a CNAME pointing to the current $ORIGIN without explicitly writing out its value. If you have a zone file with an implicit $ORIGIN (i.e. because it was specified in the config file and not in the zone) that's essential. Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Thu Jan 7 06:32:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 07 Jan 2010 06:32:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.f8b8d07d496046aff16b0e71df4f4c85@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: OpenDNSSEC + DLV (isc.org) ------------------------------------+--------------------------------------- Comment(by archi.laurent@?>): Hello all, and thanks for your answer. At my begining, i think it's possible to make this, since my local DNS, but not ... "ISC's DLV cannot find your zone since it is local. So you cannot use ISC's DLV for your zone." Sorry and good day. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 7 08:50:21 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 07 Jan 2010 08:50:21 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #70: Auditor complains about wildcard In-Reply-To: <058.1bc28827a195414365fd8410c579bacd@kirei.se> References: <058.1bc28827a195414365fd8410c579bacd@kirei.se> Message-ID: <067.17ba89dc6507d33cca2afbf30b708496@kirei.se> #70: Auditor complains about wildcard ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: alex Type: defect | Status: new Priority: trivial | Component: Auditor Version: | Keywords: wildcard auditor escape ---------------------------------+------------------------------------------ Comment(by alex): The IN CNAME @ issue is fixed in Dnsruby svn 332. Thanks for the report. I hope to get a fix for the wildcard issue soon. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 7 10:02:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 07 Jan 2010 10:02:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.37aa71dc3cea34f1d0a6a64e9e06416c@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ---------------------------------------+------------------------------------ Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: worksforme Keywords: OpenDNSSEC + DLV (isc.org) | ---------------------------------------+------------------------------------ Changes (by rb): * status: new => closed * resolution: => worksforme Comment: If you want to validate the DNS information from your local zone, then you should configure your DNSKEY in your local resolver. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 7 10:13:51 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 07 Jan 2010 10:13:51 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.3613366d11bb12814b3bd8d27b3bd00f@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ---------------------------------------+------------------------------------ Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: worksforme Keywords: OpenDNSSEC + DLV (isc.org) | ---------------------------------------+------------------------------------ Comment(by archi.laurent@?): In local i have no problem with OpenDNSSEC, Bind ... all are right. Except this under Dig : the flag "+adflag" is not activate with my Dig, but the flag "+cdflag" is ok. And the man for Dig wrote this for DNSSEC : "you can use "+topdown" and "+sigchase", but Dig do not known this options. Good day and thanks- -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 7 11:01:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 07 Jan 2010 11:01:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #70: Auditor complains about wildcard In-Reply-To: <058.1bc28827a195414365fd8410c579bacd@kirei.se> References: <058.1bc28827a195414365fd8410c579bacd@kirei.se> Message-ID: <067.afa05765d020c82ac206aa76f5065f36@kirei.se> #70: Auditor complains about wildcard ------------------------------------+--------------------------------------- Reporter: rick@? | Owner: alex Type: defect | Status: closed Priority: trivial | Component: Auditor Version: | Resolution: fixed Keywords: wildcard auditor escape | ------------------------------------+--------------------------------------- Changes (by alex): * status: new => closed * resolution: => fixed Comment: Hi - The wildcard problem should be fixed in dnsruby svn 333. Both these fixes will make the imminent dnsruby-1.42 release. Thanks for the reports. Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Jan 7 15:15:09 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 7 Jan 2010 16:15:09 +0100 Subject: [Opendnssec-develop] Meeting about the documentation Message-ID: <983F17705339E24699AA251B458249B526622A1770@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We want to have a meeting about the documentation next week (+ discuss when we should have future face-to-face meetings). Please indicate your preferred time in the Doodle: http://www.doodle.com/3kruxzb86kk48tr7 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0X6feCjgaNTdVjaAQgG0wf+M9qTulWbq9+IqnmCWSDTTujnhpkrNf1p zV+aa7bFYZ2vIUgOdLyq8MyiwwoC/C2mn4d8EOZOWd0ukcWpM6INzc0g8FvtcZ7u pRTlc64hPR5M/14wXfbvVHfVEl6m6ZU9k7b+AD14phT8X1c5OD28Iu4vI6DxOEtx CCGr6h4DTansZ69MsOx1f2LCMCnjWWsuaqS33yMjZo7/WRJ+f9rlJeaoVlnIyJhb K4F2oMwZO3BYpTACUa99krQCD5S8XzrpxAPBX2OrTNxL7emE7JqCyZvqpXrauAXR 5hDaHilXuDfcekSBo3vg2CGZ9BuZaoNm9E7bOxeM9Kuwt2Yneq7s2g== =tbk7 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Morris at nominet.org.uk Thu Jan 7 17:27:16 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Thu, 7 Jan 2010 17:27:16 +0000 Subject: [Opendnssec-develop] Known Issues List Message-ID: Following today's meeting, I've added the list of known issues to a file called KNOWN_ISSUES; it's in the same directory as README and NEWS. There's a bit of overlap between NEWS and KNOWN_ISSUES, so for rc3 and beyond, I suggest that: README is expanded to include pointers to relevant bits of the documentation (e.g. installation) where relevant, and pointers to any other text files. KNOWN_ISSUES is restricted to a list of problems in the current release NEWS contains the release history of the software (I suggest we add this to the discussions next week.) Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Fri Jan 8 08:06:41 2010 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 8 Jan 2010 08:06:41 +0000 Subject: [Opendnssec-develop] Meeting notes 2009-01-07 are online Message-ID: <20100108080641.GA21602@phantom.vanrein.org> Hello all, The notes of yesterday's OpenDNSSEC meeting have appeared on the Wiki. Cheers, -Rick From Alexd at nominet.org.uk Fri Jan 8 13:43:02 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 8 Jan 2010 13:43:02 +0000 Subject: [Opendnssec-develop] Dnsruby 1.42 release Message-ID: Hi - Just to let you know that I have now released dnsruby-1.42. I think that this addresses all known issues. It's available to download at rubyforge, or by : gem install dnsruby Please let me know of any issues. I've added a Dnsruby.version method, which the autoconf now checks on install (I think). It would be good to test that this works! I'm away for the next fortnight, so won't be able to help test - but will be able to respond to any major issues. Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Jan 8 14:16:53 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 8 Jan 2010 15:16:53 +0100 Subject: [Opendnssec-develop] Dnsruby 1.42 release In-Reply-To: References: Message-ID: <983F17705339E24699AA251B458249B526622A18E4@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I've added a Dnsruby.version method, which the autoconf now checks on > install (I think). It would be good to test that this works! I'm away > for the next fortnight, so won't be able to help test - but will be > able to respond to any major issues. I will add that check soon. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0c+VeCjgaNTdVjaAQj+rAgAmkvtl4dK9rHk/8nhrCUo6ciiW22i1mKv CbF4C8Q3tSVRlCKkZ76ozeoGX+DXo0VvB4+dwoayOZ1jtTzN7jz0Wkn18CSNDkmt ZlNThwAi2QmPkaRQUP3nC0gLvYA1dBftnQIxuPMhipVG0T6725FEHBRtwuW237VO +aCtn6vLBq4mq5vb2uaE70r+wggrN2umkQZHybL6ahRvuJy+88WXnpNZD4LfCkAV G43H0qTCij98X7/IzrnFRGw6FKNLQz+cdItwWQYFacpDkQ9eh+ouhFRMTC8E8Z+Q V0Eg3wRpobJWU5pxpWGU+if1fZUHc0pTwsu5XLZB+q3S+rdUgau1UQ== =TNFC -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Jan 11 08:33:24 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 11 Jan 2010 09:33:24 +0100 Subject: [Opendnssec-develop] Re: Meeting about the documentation In-Reply-To: <983F17705339E24699AA251B458249B526622A1770@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1770@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B526622A19B1@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Hi > > We want to have a meeting about the documentation next week (+ discuss > when we should have future face-to-face meetings). > > Please indicate your preferred time in the Doodle: > http://www.doodle.com/3kruxzb86kk48tr7 > > // Rickard The meeting will be on Friday. Date: Friday 15 January Time: 15:00-17:00 CET, 14:00-16:00 GMT Agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-01-15 // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0riVOCjgaNTdVjaAQjfMwf/VN70SQdMWOvu7kermNArofhhv+Fygn3Y rqs9gE/bwjIzbrb/cgvXSSbeO9keyeqIhI425xa8w3aAQPmHt4yOoDdkHESDfsym tYa9gxaS2de9UX114/m7xQJrMBsI08lbcqvETt+EiJ+IwxL1UfZb4UtGVYBBqKbo jb3CDT3uHI2V2r6YhgHbd70/kH4Us1huqGAof+eZ6H64zbvTwdoOf5BSNKdFYY1l 70pNF9klgf0HdVed51AEAEaiLsW5pGFNoxNsPHRicNE3aUge3ohNL571rAHhDCWu 5tORqmZLlc/Pbznav3lc3dWDB+lNZBX8hVPSPtEx4L0OjMtrlxemkQ== =33Ox -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Jan 12 08:23:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 09:23:39 +0100 Subject: [Opendnssec-develop] Optimization of the sorter Message-ID: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I have one person (Bj?rn Stenberg) that can have a look on the sorter and make it faster. That code would go into v1.1, but how should we handle the code until then? Do a branch for him? Would it be ok if he creates a new sorter with the same functionality? Would this code be useful for v2 of the Signer Engine? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0wxi+CjgaNTdVjaAQhLJggAlN1GkWj5T9eXQnaaTI155YUYqDRezRs8 kQad50bXZBfLiu4NaFDKyo0mCvVIOsdYaPjA0TppWNp/cKj5TO/s8KR+hRwf08lE rleCl4p7PYllBU9BNOf/eCThwhAvhbQC9PdozFZBEfHAu6oQzCDe1d2fC9YYiNAL JXpndF0DLHbaTGv7FqFvPa830dOTBgq6M7/XVWfXhnbxj30k5Ol/k3IQRz9cLaiV HEjpaI9xFNNC5BqE60NTPirUpUyNxIe9439IOxLD5o91hE22cTe+HGlPqgIzXg2Y amCX2xFLnCOwmBf14Boj6a7lLAGLzKhC9pw/kNwLb0f7ktwN02MXAQ== =dda5 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Jan 12 08:44:45 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 12 Jan 2010 09:44:45 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> Message-ID: <8B646DE6-3D84-4580-B5F9-117107F21CA3@kirei.se> On 12 jan 2010, at 09.23, Rickard Bellgrim wrote: > I have one person (Bj?rn Stenberg) that can have a look on the sorter and make it faster. That code would go into v1.1, but how should we handle the code until then? Do a branch for him? sure, we can do that. is it enough if we branch at rc3? jakob From matthijs at NLnetLabs.nl Tue Jan 12 08:58:44 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 12 Jan 2010 09:58:44 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> Message-ID: <4B4C39C4.1040609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: > Hi > > I have one person (Bj?rn Stenberg) that can have a look on the sorter > and make it faster. That code would go into v1.1, but how should we > handle the code until then? Do a branch for him? > > Would it be ok if he creates a new sorter with the same functionality? Sure. > Would this code be useful for v2 of the Signer Engine? I think we need to store the temporary files in a whole different way than we do now in v2. So, I'm not too sure if it is also useful for v2. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLTDnBAAoJEA8yVCPsQCW5WsoIALdJxb2+la0zRkbmPx+k8YcR OWFmVseHSHQI2MsesuK/mw2PcuaR3TjIXGMuuQWl4j0CY1a6bsDShWLT0TSWVTv/ 0hCF2o/J8/UfWo270J8V3RE8mWZSBBD1nRJ/MRjkAbnzzTBPCAFQlBuj2kpulbHw q1+OLLxu6kttNyFnR2hGryKrlXfDAAbz1zWnsfdOaHbM8i72paNc6DtODbGWe/ro MIsmyK4L8L5UQEWA2G5nsWNWTrWwShBtflGCichvJXuKP68wczTxYWC3Kys/DyRy mer7YjV2EQtAgu8x0U+H01xQS3KrAGHjm/feCq5TD5xJVa+rvI1EWGfDSHIynGQ= =Cm13 -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Tue Jan 12 09:01:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 10:01:44 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <8B646DE6-3D84-4580-B5F9-117107F21CA3@kirei.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <8B646DE6-3D84-4580-B5F9-117107F21CA3@kirei.se> Message-ID: <983F17705339E24699AA251B458249B526622A1C7C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > I have one person (Bj?rn Stenberg) that can have a look on the sorter > and make it faster. That code would go into v1.1, but how should we > handle the code until then? Do a branch for him? > > sure, we can do that. is it enough if we branch at rc3? That would be ok. I will get back to you Jakob when it is time for this (branching and accounts) // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0w6eOCjgaNTdVjaAQgHMwf7Br017GRhQ9PsNFF9qgy9/RnRgdHCOTSn RrWQ//yDvUlbDqmUuvmwtXC1cpBvUd023YewzkPmi1dsu3ayiQHLatMGxB92ADBc Rc0Tze4+kifqwQpg8bGdcVYAELvgWhHL7tiQtkm+ZMQZPqu8w7Oex15hwtbFJSFj IWU/W5KJJeQ7je4usjix5Hr08gIrmtCn6lQLxRXA2drEOqBGnD2VTI7YS+McA70T IpodkjiuHeFgo5gtxb24SJgmbvkpkf7oRasZULHoeJz1/XVLeDI/9HpP35BMklM+ wHOE4odXBA7mRG0JkhHYBZfzWIEEcEA6ZXLUE+5kSy6fqP8qIFaGpw== =NJkR -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Jan 12 11:16:45 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 12:16:45 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <4B4C39C4.1040609@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 How was the information flowing now again? Unsigned zone -> sorter -> zone.sorted (Sort the zone canonically) zone.sorted -> zone_reader -> zone.processed (Sort the zone according to the relevant signing details (either in 'normal' or 'NSEC3' space) and add DNSKEYS) zone.processed -> nseccer/nsec3er -> zone.nsecced (strips the glue from it, and adds nsec(3) records) zone.nsecced + zone.signed -> signer -> zone.signed2 -> zone.signed ((re)signs the zone) zone.signed -> finalizer -> zone.finalized (Uncomment the glue etc.) zone.finalized -> (Auditor) -> Signed zone (Output the signed zone) And if the sorting config has changed, then do this first: zone.signed -> sorter -> zone.signed.sorted zone.signed.sorted -> zone_reader -> zone.signed.processed -> zone.signed The sorter is now also flattening the zone file. Couldn't this only be done for the unsigned zone and not the internal zone. Because we could assume that the internal zone storage is ok (when sorting the zone.signed)? What is the difference between the sorting in sorter and nseccer? Or is it just that the zone is only sorted a second time if you are using nsec3er? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0xaHeCjgaNTdVjaAQhbvQgAnsCyNGiSYCqWASetfeTwzt5kcfrbV5ZZ BnSi1Syx8anXrGhZAcxozLsDk/krked97nOip+0aI9R+0l1lEzx+684mJGNvDq5l u2/t0ofNHPNieivhwkNsjK9Fa2HnAyNEwfsmP9VMvDocOyGvKjpBR+kHsPA5uyIo hLNxpt8dMy194iMYbdmSs2dYlrqCapQdwH645tcT7hBnAYEpY13OMKUJUxPmc8Me vOdiz2u4umYq7fyK4OReO8GQZX04nG7S4BF/kfRbKwHSR9K1V8nDcipHRWe7tKL4 KpAREut1ByHPF+/LQgNworYNzYBXEo5iS5dR2S/YUL0BxZbYN6UfxA== =FhkZ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From olaf at NLnetLabs.nl Tue Jan 12 11:39:40 2010 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Tue, 12 Jan 2010 12:39:40 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <4B4C39C4.1040609@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> Message-ID: On Jan 12, 2010, at 9:58 AM, Matthijs Mekking wrote: >> Would this code be useful for v2 of the Signer Engine? > > I think we need to store the temporary files in a whole different way > than we do now in v2. So, I'm not too sure if it is also useful for v2. That begs the question on how much effort folk want to put in optimization of v1. Are we looking a problem that inhibits the use of opendnssec for the core stakeholders or are we looking at an optimization that is dully needed for the somewhat longer term? Is the work done for v1.1 portable to v2? --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2210 bytes Desc: not available URL: From matthijs at NLnetLabs.nl Tue Jan 12 11:49:27 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 12 Jan 2010 12:49:27 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> Message-ID: <4B4C61C7.4060901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: > How was the information flowing now again? > > Unsigned zone -> sorter -> zone.sorted > (Sort the zone canonically) Yes. > zone.sorted -> zone_reader -> zone.processed > (Sort the zone according to the relevant signing details (either in > 'normal' or 'NSEC3' space) and add DNSKEYS) Yes. > zone.processed -> nseccer/nsec3er -> zone.nsecced > (strips the glue from it, and adds nsec(3) records) Yes. > zone.nsecced + zone.signed -> signer -> zone.signed2 -> zone.signed > ((re)signs the zone) Yes. > zone.signed -> finalizer -> zone.finalized > (Uncomment the glue etc.) Yes. > zone.finalized -> (Auditor) -> Signed zone > (Output the signed zone) Yes. > > And if the sorting config has changed, then do this first: > zone.signed -> sorter -> zone.signed.sorted > zone.signed.sorted -> zone_reader -> zone.signed.processed -> zone.signed If certain parameters in the config have been changed, different processing might be needed. Sometimes the zone is rescheduled to reNSEC, sometimes to re-sort, sometimes just re-signing is needed. > The sorter is now also flattening the zone file. Couldn't this only be > done for the unsigned zone and not the internal zone. Because we could > assume that the internal zone storage is ok (when sorting the zone.signed)? Yes, we could skip flattening by setting another command line option. > What is the difference between the sorting in sorter and nseccer? Or is > it just that the zone is only sorted a second time if you are using nsec3er? nseccer does not sort. zone_reader does a different sorting if NSEC3 is used. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLTGHGAAoJEA8yVCPsQCW5XN0IAKzU47ywh5RExRLuAF6X3BII m3mv3VFAmS+kqkE0GIYztXeqlknIBYXW9tUsKiRLLLfgcW4RHUkRZs44dmenjI2K /EkgByZ6WXuY1KWMOnYsIPNKQ0HOGTmhNbsoLC2I2zbqN9ngu110JgXzS593RK7B LixG4eCEuaf1hPmYVUUAkLk9L/xujK7TUJi2QnJ3FO2OyMoLQsihA6N5cJgyjjyK 9WV7Dzw7AdhKc3/FMSibH7U7b2/CuJ3vDjlL02bx3e6lySUYgo7W7DAqC8u00fUs MCA0/4IwNWZTJoVDq1oj/7BC2M9K9mbHM/UAoJHG33JztsXp5iZyOpdP2WuwF14= =yXTc -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Tue Jan 12 12:15:06 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 13:15:06 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B526622A1D4F@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > That begs the question on how much effort folk want to put in > optimization of v1. > > Are we looking a problem that inhibits the use of opendnssec for the > core stakeholders or are we looking at an optimization that is dully > needed for the somewhat longer term? Is the work done for v1.1 portable > to v2? The current solution is working for us now, but we need better performance in the future (for others with larger zone than .SE). We are currently just looking at the sorter and I think that the new code could be useful in the future as well. Just get the zone info from database/memory/pipe/etc instead of a file. For 1.1 we do not want any big changes, because that would distract us from 2.0. The overall optimization of OpenDNSSEC is a topic that needs to be discussed in the meeting in Amsterdam. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBUAwUBS0xnyuCjgaNTdVjaAQiXlwf4qOkOhm+DvDZTbwXybQX34sfWutLOpmDz KOvoSBD0nvmWPAkUs8QAZWHrDGuWA6fW0PLtvNbbDr7UP5ca8ja2KPBEfbx8Wq44 tiiFX616RKwvhIPZSh2+U/tpVdYmz+AljrsmS/Wp3mx2kLiyoFydN/fxqGWvrISh GAQ+t/7Gyo5+wTiS+vCTMpiPdlmGxy+SrDOGGuSUx4pW2s4JSGFWmOJqNwKX/TFs pxXjm9AofAV95W1a0NdUc1RvVnt45hNKlhMccJFAd2bFp2ndecAxAE2LxKx0cVrY d6NumbRphcPHk+NcI+iGacveN4ww/d1Wz9AZbXeu4VBkDlM9p1X0 =5hT7 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue Jan 12 12:28:36 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 13:28:36 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <4B4C61C7.4060901@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> <4B4C61C7.4060901@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B526622A1D5B@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > The sorter is now also flattening the zone file. Couldn't this only > be > > done for the unsigned zone and not the internal zone. Because we > could > > assume that the internal zone storage is ok (when sorting the > zone.signed)? > > Yes, we could skip flattening by setting another command line option. Thank you, now I can better explain to Bj?rn what we are doing with the internal zone handling. I can recommend to him to split the parsing and sorting into two parts, where parsing is only done upon request. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0xq9OCjgaNTdVjaAQh8Dgf/bbrJgOZRBzhIpT4lmFD2dLUEbuQOETpO ZaenJKCVPHanemUN6798IUKteiawZ2llOAfuvKEHBdyRzXY+BZVRsvBM8dvpoDQ7 U7CBtF7/w+2D2X+Q2XWsLakTzDFvqeSsL2E6+++K6XefM97YjyZM1yf85dv+n/w0 +9H2suWZLEdRTHtjiObcVPMt2lnzelqa/g5LM7trFDSQxX4KZkxkAoaMRXZ77FQZ cWRJQteGSMuimUd7fzexRKkvPg22gLF275n/rRpWNPHRXjWHt3Zw/pFlwYpN0jXD 108vPopNgW86iVudCoNrHJ26uxDNtMh3DEgASsbUyBkK2YTWXfYzaA== =0IEL -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Tue Jan 12 13:14:14 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Tue, 12 Jan 2010 14:14:14 +0100 Subject: [Opendnssec-develop] EPP client plugin Message-ID: <06E45E37-0F83-4EFA-8D23-906ED51A6746@iis.se> I have made a specification for an EPP client plugin to OpenDNSSEC. It requires some small additions to OpenDNSSEC itself, which we might add for 1.1. If you have time to read it, please send comments to me. http://trac.opendnssec.org/wiki/Plugins/EPP -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From rickard.bellgrim at iis.se Tue Jan 12 16:38:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 12 Jan 2010 17:38:44 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <983F17705339E24699AA251B458249B526622A1D5B@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> <4B4C61C7.4060901@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D5B@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B526622A1EE8@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Thank you, now I can better explain to Bj?rn what we are doing with the > internal zone handling. I can recommend to him to split the parsing and > sorting into two parts, where parsing is only done upon request. A question from Bj?rn: Is it ok to keep a comment that is on the same line as a RR? Would something break later in the chain? A comment will be dropped if there is no RR before it on the same line. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS0yllOCjgaNTdVjaAQhArQgAnTE49uEJf3ytXVjToflFeGAHUrhMZcII fdmed0Aqc1eBUTFDq/uW5RB6HFdAsdGWji8Cfchll/Wn/xGNwSgBj1pN5/xREDAz /5WjXGG1tnqs3VrmD4p3fsoaHfRL0vqUjJuCot3yK6A5Z1PnEK0Cu0Ld1s01svgD r/zWEdBigUVzqWrJJImIYnPasRiDLE22oZoGoAHPSiPNxbOgmt6EiOXYp+MCKrBk 6zl7v4HxKQhQgP4arAdIL6FX3wNFgNWdcq7+st5rrSL938h1wXi/Pije4kYHyJ5O R1HKZ+oakg602yHZgb3Nx8gyDnXB52DdFvu6629DER7iSbFrIx8myA== =vN5J -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Tue Jan 12 16:54:45 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 12 Jan 2010 17:54:45 +0100 Subject: [Opendnssec-develop] Enforcer keeps running Message-ID: <850A39016FA57A4887C0AA3C8085F949014D868A@KAEVS1.SIDN.local> Hey, I used "ods-control stop" to stop both deamons. However I am getting this message: Stopping enforcer... Cannot find PID file Stopping signer engine.. connecting to /var/run/opendnssec/engine.sock Sent stop command to engine And the Enforcerd just keeps running. Where is the PID supposed to be? How can I recreate one? Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Tue Jan 12 19:05:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 12 Jan 2010 19:05:26 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #72: The "" Message-ID: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> #72: The "" ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: new Priority: trivial | Component: SoftHSM Version: trunk | Keywords: ------------------------------------+--------------------------------------- Hello all, In your documentation there are many information for use OpenDNSSEC, but for in kasp.xml, for me, there is no a very explain for activate this. It's a mistery. And same is funny for me, i prefer make the manual rollover by "ods- ksmutil" for rollover a key, your do not have a explain for activate. Many thanks for this. Best regards -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Wed Jan 13 08:16:00 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 13 Jan 2010 09:16:00 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <983F17705339E24699AA251B458249B526622A1EE8@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> <4B4C61C7.4060901@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D5B@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B526622A1EE8@EXCHANGE2K7.office.nic.se> Message-ID: <4B4D8140.7000309@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: >> Thank you, now I can better explain to Bj?rn what we are doing with the >> internal zone handling. I can recommend to him to split the parsing and >> sorting into two parts, where parsing is only done upon request. > > A question from Bj?rn: > Is it ok to keep a comment that is on the same line as a RR? Would > something break later in the chain? A comment will be dropped if there > is no RR before it on the same line. It's ok to keep a comment on the same line, just be aware that when ldns is creating a new RR from string, it will ignore these anyway. And thus when writing back the RR, the comments will still be lost. I guess that can be fixed by introducing new variables in the curr_rr_data structure. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLTYE5AAoJEA8yVCPsQCW525oIALwDuUS+Qmz/YrB6jOJzYsEq HSTwExGKblfFi4bP0LRa4uzgxgdoghLK3qzSPI30aTqvurwm9+deoQD5e8lza1b7 7Jeby3wLvPrY0s25jKNol3W7U8VxV7leZIpatL8GhpBZ4dx9N4YjD6BNcCig5M/R iyttGnL8NRddrMDu0Y+dL4/dkT/v5FcmABlZu/gHkQ32vofnJn5wwWfwpV53+DWW Q1b4tM/v+5lBdUG/v+HVGn+B2e58Iw0MKtMHOJv205gCxZe8t0Yh1fceecz5bTWl 9s4svZiPVnaN5kkJZgu7nnsKwomsL/USscjPS+pYyGBCB5gJUEw9mY+ffECMvnE= =135d -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Wed Jan 13 08:21:48 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 13 Jan 2010 09:21:48 +0100 Subject: [Opendnssec-develop] Optimization of the sorter In-Reply-To: <4B4D8140.7000309@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B526622A1C37@EXCHANGE2K7.office.nic.se> <4B4C39C4.1040609@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D2C@EXCHANGE2K7.office.nic.se> <4B4C61C7.4060901@nlnetlabs.nl> <983F17705339E24699AA251B458249B526622A1D5B@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B526622A1EE8@EXCHANGE2K7.office.nic.se> <4B4D8140.7000309@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B526622A1F46@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > It's ok to keep a comment on the same line, just be aware that when > ldns > is creating a new RR from string, it will ignore these anyway. And thus > when writing back the RR, the comments will still be lost. Ok, good. > I guess that can be fixed by introducing new variables in the > curr_rr_data structure. No need for that. Just checking so that we do not break anything if the sorter will write a file where some of the comments are kept. Thanks // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS02CnOCjgaNTdVjaAQjWCgf+J2K/YBVeNT6Zjje3RN7flCveR26qBovI 2riAjvvpdt/NYliJgueomCDE0EmHgzJb1XNdCfmH7dI7feJI94ivDDJCz7kNeNk7 aalqSi6bTHiZ+2FqQrKQdfXpTHBCXVSkAMLCuEZP+R6ybFCVV8WaWYNmHMT56qic ax+2G8x3g6gk+UYNiBfyojLfG0iypRgfcEGMV7OlM1mdVjQseTSCgRmDSHx+eA9R Q+pTQsoCaaDKqMZsNlRdQXRQVKfGjui1pphG1w7BQOPvcRJrUJPsu38w05hAB3Pf OCUg7XlWQnErKi7+Fjss5auLjlP/2SCEDec3gHG9iFmJAymAnNsy4w== =WNkO -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Jan 13 08:32:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 13 Jan 2010 08:32:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #72: The "" In-Reply-To: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> References: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> Message-ID: <070.f37689123ddf8f3e6511bd7b14d6a4b9@kirei.se> #72: The "" ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: assigned Priority: trivial | Component: SoftHSM Version: trunk | Keywords: ------------------------------------+--------------------------------------- Changes (by rb): * status: new => assigned Comment: Thanks for your comments. I have updated the documentation. The are used to mark text as a comment. Remove these and the tag will be used. If multiple zones are associated with a policy, the presence of indicates that a key can be shared between zones. E.g. if you have 10 zones then you will only use one set of keys instead of 10 sets. This will same space in your HSM. If this tag is absent, keys are not shared between zones. is an optional tag. This tag indicate that the key rollover will only be initiated on the command by the operator. There is still a second step for the KSK, where the key needs to be published to the parent before the rollover is completed. Read more in the chapter "Running OpenDNSSEC". The ZSK rollover will although be fully automatic if this tag is not present. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 14 08:30:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 14 Jan 2010 08:30:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #72: The "" In-Reply-To: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> References: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> Message-ID: <070.5edd884bd456c767dc1e3d4e853369ce@kirei.se> #72: The "" ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: assigned Priority: trivial | Component: SoftHSM Version: trunk | Keywords: ------------------------------------+--------------------------------------- Comment(by archi.laurent@?): Hello all, and thanks a lot - Best regards, all are perfect. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 14 08:33:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 14 Jan 2010 08:33:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #72: The "" In-Reply-To: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> References: <061.3b2ef2339c5bd7d38460a70dedf3cb12@kirei.se> Message-ID: <070.7c1b3e0168a01b71597ef712edbcb520@kirei.se> #72: The "" ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: closed Priority: trivial | Component: SoftHSM Version: trunk | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Jan 14 17:01:37 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 14 Jan 2010 18:01:37 +0100 Subject: [Opendnssec-develop] Drop NSEC3PARAM from input zone Message-ID: <983F17705339E24699AA251B458249B526622A244B@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The sorter does not drop the NSEC3PARAM from the input zone. But we are dropping NSEC, NSEC3, and RRSIG. The NSEC3PARAM is removed later on, but couldn't this be done in the sorter? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS09N8eCjgaNTdVjaAQh9uggAmpjRPuTjIsqj/jvSL7r3RKuyRHLvPpcG l4khouPzyX63Lrj9eVahUJcOjCBnMQb9F4ZPMbtqnfTPJ7JKzEZv3XFmwTV6IPTN oxbCT8KeLd+iAaKqIS3BgTzIoCG7efC6GmV89Cpuv7baOxqJXqd/qKVJspYCa2c8 eVxadBMhjzpAT+HZ+pLCVpeArAzWVySceh8dgOelOPECG7k/zSaP3IPrU9VVJcn+ 2mvxWV38B+1EyAurwWRkAw83UiLDRukk1msS2rJ4uOrlz6UY1TEPLfiOK+uEcoGJ z1roABIly6+fPp9smCQ15/RvIV/nyO2U4NqmJqUnXrlFW+Ndy5Izsw== =BLqW -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Jan 15 08:22:10 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 15 Jan 2010 09:22:10 +0100 Subject: [Opendnssec-develop] ldns problem parsing TSIG from zone transfer with dig Message-ID: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi I have a copy of the se zone on my development machine. It is fetched using the dig command. But when I try to sort it with OpenDNSSEC I get this: rickard at fou:~$ time /usr/local/libexec/opendnssec/sorter -f /var/cache/bind/se.bak -w se.sorted -m 3600 -o se. Warning: Syntax error, could not parse the RR's rdata: 486: fou.20080513.tsig. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1263522721 300 16 y8EsZca1XIfZT07GFEtvLQ== 26668 NOERROR 0 There are over 4000 TSIG in this file. Is there a flag to dig so that it does not add those? Or a fix to ldns so it can parse it. Is the RR class wrong? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1AlsuCjgaNTdVjaAQhGwwgAlWD7H91kt02GeZ+3hsalVeycHX8lxsAw gfrheLyGfrS9z1tH6lmZheMwqFc5EVIwCWIdGQV2Nf07a/S+5wlxKqY+VTSqiUbz KyTTLsCUxpE88lzIPM2y6nuVAe4DlyY9G0AShniboSnb1/r9pdWwTxgxPpOG/ayH tdbOZuND0s2i1IoFXyYe03si37Ij5JoE31s69Ns5NmmgQF1CA4eQR9GorL+OWJMt HjC98No7QsXQwC9WduPui06pyTbq39Lp2KQNbhbAhjkShkGPUB/04NNLXRu4hoMh bqRNklLV1GdfWFDuJ+Btlby3/floDF/vowgfIUqsoklmBi7NbczwtA== =tEEI -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Jan 15 08:24:25 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 15 Jan 2010 09:24:25 +0100 Subject: [Opendnssec-develop] ldns problem parsing TSIG from zone transfer with dig In-Reply-To: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> Message-ID: <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> On 15 jan 2010, at 09.22, Rickard Bellgrim wrote: > 486: fou.20080513.tsig. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1263522721 300 16 y8EsZca1XIfZT07GFEtvLQ== 26668 NOERROR 0 there should never be any TSIG RRs in a zonefile on disk. how did you get this file? jakob From rickard.bellgrim at iis.se Fri Jan 15 08:28:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 15 Jan 2010 09:28:20 +0100 Subject: [Opendnssec-develop] ldns problem parsing TSIG from zone transfer with dig In-Reply-To: <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> References: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> Message-ID: <983F17705339E24699AA251B458249B526622A24AC@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > 486: fou.20080513.tsig. 0 ANY TSIG hmac-md5.sig- > alg.reg.int. 1263522721 300 16 y8EsZca1XIfZT07GFEtvLQ== 26668 NOERROR 0 > > there should never be any TSIG RRs in a zonefile on disk. how did you > get this file? dig -y key axfr se > file // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1AnJOCjgaNTdVjaAQjedwgAmdFirYAGHvi31Dh4YQgxlP4xnMrsi1NZ CUMzUX3MEW9wBkXdPwpVnIKbv8N+WBaJzde/0x4d94gYKhj27JsGTo8oXSzdq2hI O3nlzTeIeDPdnsZwHiYaGhvnPIKRYpJAbHCCgRlUVlvd646Iqcv0CI7ZjB3i2pR2 dGThSYRFurv9vvV3zYk67OTZHd8Ios6E2zi8eOglRO/EXbg/teAK/KMcUEUdv+mi DIrhXyuePnwXjsBrDyNpnA+bDLeNU4TKf0IiN7gjOojOOWXIr5PH83jCAttha5wl Q3GKOinH1djmqCF6Oa5Gn9KTwh38Gj5Z8sQB9bXL3u98jO4myh29gg== =B03B -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri Jan 15 08:30:48 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 15 Jan 2010 09:30:48 +0100 Subject: [Opendnssec-develop] ldns problem parsing TSIG from zone transfer with dig In-Reply-To: <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> References: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> Message-ID: <983F17705339E24699AA251B458249B526622A24B1@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > 486: fou.20080513.tsig. 0 ANY TSIG hmac-md5.sig- > alg.reg.int. 1263522721 300 16 y8EsZca1XIfZT07GFEtvLQ== 26668 NOERROR 0 > > there should never be any TSIG RRs in a zonefile on disk. how did you > get this file? It's an automatic script that has run on the machine for a long period of time. That is why I have not been using the zonefetcher. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1AnuOCjgaNTdVjaAQi/vQf/dE1cJWtX83y36BwFOejuQsHUnzKvUA09 rgRm3nQHCvwQjPWUxdkvJe5G+fyMSRqKYPwmUpzke+HZ4GUsmht5yw4MTvnkOTbr S0/4kyg8/k6pIvfzd2wbhn0ue5HHkxQRvVcTGEG2fy4gZxeidKSRm/40vLd/vY+L 7D6akP4vwrZphF/s5wof9YWXHcwfK+qPvN1Ss3XxLpMehSbeN4pGzMtSkDQoQ7el vknBTo3mrrDCk/0rXkwN8kx7/b73tKcIH61aWiCOT0WFcrirOVhr+duapihHkhN+ 497H3fTSELjhtZIm6cKfVgDh3Jw75HGZ4sPGtTlUN06fwX26xu6EXg== =YBTS -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Fri Jan 15 08:31:24 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 15 Jan 2010 09:31:24 +0100 Subject: [Opendnssec-develop] ldns problem parsing TSIG from zone transfer with dig In-Reply-To: <983F17705339E24699AA251B458249B526622A24AC@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B526622A24A6@EXCHANGE2K7.office.nic.se> <052589B0-5B47-4876-BACD-04F4D3B9BEBC@kirei.se> <983F17705339E24699AA251B458249B526622A24AC@EXCHANGE2K7.office.nic.se> Message-ID: <288E099E-9276-4775-8C9F-FA66E9C19379@kirei.se> On 15 jan 2010, at 09.28, Rickard Bellgrim wrote: > dig -y key axfr se > file that is NOT a zone transfer program - that's a debug tool. please do not use dig for zonetransfer, use the zonefetcher as intended. jakob From Stephen.Morris at nominet.org.uk Fri Jan 15 22:22:49 2010 From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk) Date: Fri, 15 Jan 2010 22:22:49 +0000 Subject: [Opendnssec-develop] Notes from Teleconference 2010-01-15 Message-ID: Notes from the today's teleconference on documentation can be found at: http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-01-15 Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Jan 18 09:55:51 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 18 Jan 2010 10:55:51 +0100 Subject: [Opendnssec-develop] Action points from the last meeting Message-ID: <983F17705339E24699AA251B458249B526624A7701@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The website and the documentation needed a lot of improvements. We had a set of action points, which I now have divided among us. Hopefully we can finish these tasks this week. Sion ? Do the changes for the ?Installation? chapter in the documentation. See the minutes. ? Move the ?Command utilities? chapter after the ?Running OpenDNSSEC? chapter in the main content list. ? Have a look on the ?Command utilities? chapter and see that the text is up to date. Perhaps some restructuring. ? Create a ?Troubleshooting? chapter and add text for the Enforcer. Matthijs ? Do the changes for the ?Configuration? chapter in the documentation. See the minutes. ? Restructure the ?Running OpenDNSSEC? chapter in accordance with the minutes. ? Add text about the Signer to the ?Troubleshooting? chapter. ? See if there is more text to add to the F.A.Q. Have a look on the user?s list. Rickard ? Do the changes for the ?Features? page. See the minutes. ? Do the changes for the ?HSM Buyer's Guide? page. See the minutes. ? Do the changes for the ?Download? page. See the minutes. ? Do the changes for the ?Migration? chapter in the documentation. See the minutes. ? Add text about the SoftHSM to the ?Troubleshooting? chapter. Patrik ? Extract the documentation from the wiki and add it to the website. ? Make the submenu items clearer in the main menu. ? Prepare a page where we can add a list of known users. With some info on how to be added to the list, e.g. send a mail to the user?s list. Rick van Rein ? Go ahead with your suggested changes to the documentation. Jakob ? Do the changes for the ?About? page. See the minutes. ? Do the changes for the first page. See the minutes. ? Move the text from the background part of the documentation to the ?About? page. Add a link to the documentation which refers to the about page. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1QwJ+CjgaNTdVjaAQhp/Qf/b9WsBZ0ul1WeDzUo4neACSxEDYhrPNS0 F2ghi899n74CoimEgY67C2kVqOLXV4lDEGa5fmODG0oTjsFgYW2DYxi45E2WU1sU fW6zB6XCuXj/ApscF2nsy3CcCOUuJXI5SVOBt7AtaeGo5cswTJr/Ou2X7O76BAG1 ht2CmS6ucg8S9NaI/IfPrGshNW1cPCMOqTfQ4N1+34czzxplhHYFQvYVpDt/ifuv q4b+j5xGmYq+NVb2kwQFJOunNmc1e9iX1x87NHJnp8VsYupAw6UVhbLhQEqTJRRK 8Z0H8ougHkXc7xCLclpXamlDOB9E0L4zk2l/JCHDytvn9xle5gP3mA== =7ET4 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Jan 20 09:21:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 20 Jan 2010 09:21:41 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #73: Keytag checked overzealously? Message-ID: <058.cee747f4184629e9de4cbe89fcd6ec63@kirei.se> #73: Keytag checked overzealously? ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: sion Type: enhancement | Status: new Priority: trivial | Component: Enforcer Version: | Keywords: ---------------------------------+------------------------------------------ I did something awful -- I deleted a public key in the HSM by going under OpenDNSSEC. So what follows is certainly not a showstopper for 1.0, but it did seem unpractical how OpenDNSSEC responded. Platform was RC2. ksmutil lists the half key as "NOT IN repository", which is a very clear indicator of the exceptional situation. But when I try to roll it (using the CKA_ID, lacking the keytag) I get a complaint from ksk-roll that I don't quite understand to be a necessary hurdle to recover from a missing key. After ksmutil key rollover I did/got: [root at apollo ~]# ksmutil key ksk-roll --zone openfortress.nl --cka_id 20a4f17382d2e9fcb73e01d58c4cc167 *WARNING* This will retire the currently active KSK; are you sure? [y/N] y SQLite database set to: /var/opendnssec/kasp.db Error: keytag "(null)"; should be numeric only It turns out that I am stuck with a key that doesn't want to work anymore -- and I don't think this is desirable behaviour, if it can be avoided. Should the keytag-is-null perhaps be tuned down to a warning to improve the practical usefulness of OpenDNSSEC? This is not just sillyness -- storage space in an HSM is expensive, so I am seeing if I can avoid using it for public keys. I will also try if I can store the public key on a cheaper medium. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 20 09:29:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 20 Jan 2010 09:29:43 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #73: Keytag checked overzealously? In-Reply-To: <058.cee747f4184629e9de4cbe89fcd6ec63@kirei.se> References: <058.cee747f4184629e9de4cbe89fcd6ec63@kirei.se> Message-ID: <067.9e232a3582fd81e2936c45f4d505be50@kirei.se> #73: Keytag checked overzealously? ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: sion Type: enhancement | Status: new Priority: trivial | Component: Enforcer Version: | Keywords: ---------------------------------+------------------------------------------ Comment(by sion): This looks like it might be the same issue as ticket #65; in which case it was fixed in r2664 (post RC2). The problem is that you can not specify ONLY the cka_id... But you need to give the keytag also. However, I have not tried it in the situation you describe, so it may well still fail. I'll leave this ticket open until we know that it still works. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 20 09:49:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 20 Jan 2010 09:49:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #73: Keytag checked overzealously? In-Reply-To: <058.cee747f4184629e9de4cbe89fcd6ec63@kirei.se> References: <058.cee747f4184629e9de4cbe89fcd6ec63@kirei.se> Message-ID: <067.a5b98c1da426fd63cd26b086c5f328e9@kirei.se> #73: Keytag checked overzealously? ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: sion Type: enhancement | Status: closed Priority: trivial | Component: Enforcer Version: | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Changes (by vanrein): * status: new => closed * resolution: => fixed Comment: Thanks, Sion. I backported the patch and found the message gone. I closed the issue. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Jan 21 09:07:59 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 21 Jan 2010 10:07:59 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with Message-ID: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi The ldns 1.6.4 has been released. So now I started to test everything once again. My normal zones just works great, but I found one extra zone in our SVN to test with, all.rr.binary.org. The Auditor did not like the result. But it looks like ldns is doing it right. The records are present in the signed zone, but with trailing dots in the rdata (which dnsruby seems to believe that they shouldn't). 3: Output zone does not contain non-DNSSEC RRSet : NS, \\.all.rr.binary.org. 60 IN NS ns1.example.com.\000 3: Output zone does not contain non-DNSSEC RRSet : TXT, selector._domainkey.all.rr.binary.org. 60 IN TXT "v=DKIM1; n=Use=20DKIM; p=AwEAAZfbYw8SffZwsbrCLbC+JLErREIF6Yfe9aqsa1Pz6tpGWiLxm9rSL6/YoBvNP3UWX91YDF0JMo6lhu3UIZjITvIwDhx+RJYko9vLzaaJKXGf3ygy6z+deWoZJAV1lTY0Ltx9genboe88CSCHw9aSLkh0obN9Ck8R6zAMYR19ciM/; t=s" 3: Output zone does not contain non-DNSSEC RRSet : SRV, _http._tcp.all.rr.binary.org. 60 IN SRV 0 5 80 ns1.example.com 3: Output zone does not contain non-DNSSEC RRSet : MINFO, all.a{ll.all.rr.binary.org. 60 IN MINFO minfo-rmailbx.example.com minfo-emailbx.example.com 3: Output zone does not contain non-DNSSEC RRSet : PTR, foo.all.rr.binary.org. 60 IN PTR \000\\.ns1.all.rr.org 3: Output zone does not contain non-DNSSEC RRSet : CNAME, \032.foo\..all.rr.binary.org. 60 IN CNAME \\\\\..ns1.all.rr.org 3: Output zone does not contain non-DNSSEC RRSet : DNAME, frobozz.all.rr.binary.org. 60 IN DNAME frobozz-division.acme.example 3: Output zone does not contain non-DNSSEC RRSet : MB, nall.all.rr.binary.org. 60 IN MB mb-madname.\000.example.com 3: Output zone does not contain non-DNSSEC RRSet : A, ns1\..all.rr.binary.org. 60 IN A 10.1.0.52 3: Output zone does not contain non-DNSSEC RRSet : DS, sub.all.rr.binary.org. 60 IN DS 12345 DSA 1 ( 123456789ABCDEF67890123456789ABCDEF67890 ) So it looks to me that the problem is in dnsruby. We can have a release of RC3, but perhaps stating that the auditor has some problems with binary domain names. Or what do you say Matthijs? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1gZb+CjgaNTdVjaAQgoKQf9Gb3y8lBkb+JnzviSWDY7aEUpgWlPU7wv DqwqxfXvB4eXht/uVTze4f9lzNMSWEAwop2zxnGRinTJEutEbBWOi/ilfgxlPAZ9 M7FN6EeVa9ouNq89v6xX5O0EJwQOPuwN3dogTZA2IWkpnqy99gH1yAfOL9RBzDg/ h+hMQ/2HfctTxoJqdhAAhrb+rmsOP6JKogQXkPhX58Qp1T/pkPoXLYlPna/Jg+/l Jo4/gMjmc56SzrqoevuQLhgmXP5/3PYr68uiyxxXD8gUTWCWdewilppzw6UCsc9G HRw9EFS4JI/5oRow+JdLv6sSymRuoligAY0TzPOTeQUb8gmW9C3N1A== =BfnZ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Thu Jan 21 11:14:35 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 21 Jan 2010 12:14:35 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> Message-ID: <4B58371B.2080404@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the trailing dots are already in the unsigned zone file, so from a ldns perspective that looks good. I tested it on my machine, and I did not get these errors. I did get signature verification failure for the DNSKEY. It seems that if there is a DNSKEY with a different TTL than //Keys/TTL, it is assumed a different RRset. A fix is committed soon. Also, I got an error that the NAPTR record was not the same as in the output zone, but I think is a false report from the auditor: Input: all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . Output (.finalized): all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@([^.]+.)(.*)$/2/i" . Auditor believes output was: all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@[^.]+..*$/2/i . Matthijs Rickard Bellgrim wrote: > Hi > > The ldns 1.6.4 has been released. So now I started to test everything > once again. My normal zones just works great, but I found one extra zone > in our SVN to test with, all.rr.binary.org. > > The Auditor did not like the result. But it looks like ldns is doing it > right. The records are present in the signed zone, but with trailing > dots in the rdata (which dnsruby seems to believe that they shouldn't). > > 3: Output zone does not contain non-DNSSEC RRSet : NS, > \\.all.rr.binary.org. 60 IN NS ns1.example.com.\000 > 3: Output zone does not contain non-DNSSEC RRSet : TXT, > selector._domainkey.all.rr.binary.org. 60 IN TXT > "v=DKIM1; n=Use=20DKIM; > p=AwEAAZfbYw8SffZwsbrCLbC+JLErREIF6Yfe9aqsa1Pz6tpGWiLxm9rSL6/YoBvNP3UWX91YDF0JMo6lhu3UIZjITvIwDhx+RJYko9vLzaaJKXGf3ygy6z+deWoZJAV1lTY0Ltx9genboe88CSCHw9aSLkh0obN9Ck8R6zAMYR19ciM/; > t=s" > 3: Output zone does not contain non-DNSSEC RRSet : SRV, > _http._tcp.all.rr.binary.org. 60 IN SRV 0 5 80 > ns1.example.com > 3: Output zone does not contain non-DNSSEC RRSet : MINFO, > all.a{ll.all.rr.binary.org. 60 IN MINFO > minfo-rmailbx.example.com minfo-emailbx.example.com > 3: Output zone does not contain non-DNSSEC RRSet : PTR, > foo.all.rr.binary.org. 60 IN PTR \000\\.ns1.all.rr.org > 3: Output zone does not contain non-DNSSEC RRSet : CNAME, > \032.foo\..all.rr.binary.org. 60 IN CNAME \\\\\..ns1.all.rr.org > 3: Output zone does not contain non-DNSSEC RRSet : DNAME, > frobozz.all.rr.binary.org. 60 IN DNAME > frobozz-division.acme.example > 3: Output zone does not contain non-DNSSEC RRSet : MB, > nall.all.rr.binary.org. 60 IN MB mb-madname.\000.example.com > 3: Output zone does not contain non-DNSSEC RRSet : A, > ns1\..all.rr.binary.org. 60 IN A 10.1.0.52 > 3: Output zone does not contain non-DNSSEC RRSet : DS, > sub.all.rr.binary.org. 60 IN DS 12345 DSA 1 ( > 123456789ABCDEF67890123456789ABCDEF67890 ) > > So it looks to me that the problem is in dnsruby. We can have a release > of RC3, but perhaps stating that the auditor has some problems with > binary domain names. > > Or what do you say Matthijs? > > // 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLWDcWAAoJEA8yVCPsQCW5JhMH/3zTqdCARbVZahEnKJnbgwbQ 0Q1/K1fdHPdBv7IeEAVl4rtuTnYKc6Awwhx7DsYhQqZsnYmNvi+Wm5ymRj4mMjTQ wCuQn6gkCYv/71B1siJTMuUkNIjeq9GWWpC4p3Hs35pHJBzTLjoF0eUthMJX2ez5 jMK017OyP010E2i8DuWFD8wxBFJzCxyWAJN3gC2RB9wjOeo7gp/GI9z647YPStsy p57StRh4UUtJ70PJ6k0uEZYNEi1eMd/HHd9DjhITajjCBEB15xKPHPecywiF6gs9 WVKeD/2d5q9OGuKw3pcqFixpuisMmPaKNIO8EpaBPW2iZd0QtKsmKvqdjCO4XvY= =2YyI -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Thu Jan 21 11:29:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 21 Jan 2010 12:29:39 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <4B58371B.2080404@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B527EEEEFAA6@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Also, I got an error that the NAPTR record was not the same as in the > output zone, but I think is a false report from the auditor: That is fixed in r2687. The NAPTR in the test zone was not properly escaped. -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1g6o+CjgaNTdVjaAQi40Af9HTG2J592fyOLVrLTpb7bpPX1TrtCiIht bkWWkikuhkC9ApMGd6BPyIHIVSKyIhd403/9NsFpNNF2/ZR5GViNUhgmuTcI3qc5 JGD9eBRnHXcVNVQF5gno3g0cSDKELbDD5Q7RhuhnMv5a9e0fSeSJuCVsnuU2ym7i LXLdngqV/evJhJpqKiAldX79EAYvrB5Bh3MfaQhuIELQIKXbQi54DHuBp7K92pX+ awd4Ub03lMfHYO5pucG4AWfGfaJtAjHjD9LTohUwqal6txo/tYie/N+50kD69L5I X0/MInnaVIJ3axwN6i66Wmh4I+3dd8+y2jkJR5HlybdFKQ+yZoGI2w== =smXg -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Thu Jan 21 11:44:40 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 21 Jan 2010 12:44:40 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <4B58371B.2080404@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> Message-ID: <983F17705339E24699AA251B458249B527EEEEFAAE@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > It looks like the trailing dots are already in the unsigned zone file, > so from a ldns perspective that looks good. > > I tested it on my machine, and I did not get these errors. Perhaps a problem related to my version of ruby (1.8.6) and dnsruby (1.42). > I did get signature verification failure for the DNSKEY. It seems that > if there is a DNSKEY with a different TTL than //Keys/TTL, it is > assumed > a different RRset. A fix is committed soon. Do all of the DNSKEYs need to be in the same RRset? So the DNSKEY in the unsigned zone gets manipulated to have the same TTL as the ones created by OpenDNSSEC? // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS1g+KOCjgaNTdVjaAQjc1ggAjLndjYfHFdhOhTquK3b4OLcpeuP6K0xF 48MOUkpGpeMNelqxtWv4D9Mve3Rm8KwHH63dH6qJw3rjV+UWTUvrh8FkKxgmUANQ 1GIQHq86q7rAm7c8uaHgM38YxUnPIak1hy4oxTxf1ZY6MqCohN4FmvQ8RM9vSDvd VKBJkBIOF3UQoxzcbBqqFXZtwv2gs1OaEyL7Csk8VKOjpvmaWhVY3Ab6C5mfmeM3 bvg+F1jRkrhWSk0+6waIHWQBSCLa7xgkxrzm0GkIPrDkab/oDWS7MckaDB3VTKz3 EnPnjYNtqCL77d30aG2DLjumqU5GME5azZdgEkaoPsV1ZBCcVSc/MA== =zZB7 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Thu Jan 21 11:49:13 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 21 Jan 2010 12:49:13 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <983F17705339E24699AA251B458249B527EEEEFAA6@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> <983F17705339E24699AA251B458249B527EEEEFAA6@EXCHANGE2K7.office.nic.se> Message-ID: <4B583F39.4030808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rickard Bellgrim wrote: >> Also, I got an error that the NAPTR record was not the same as in the >> output zone, but I think is a false report from the auditor: > > That is fixed in r2687. The NAPTR in the test zone was not properly escaped. > Yes, but even a bogus NAPTR record should be properly validated by the auditor, imo. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLWD83AAoJEA8yVCPsQCW5fOgH/RvLp4Jup3baWjKDJ67AiYw2 Z79+EDdMHkoYuHUq88NwuEKXFt5ybMVJ4mj/bw1R6RzBQu6JlGptpFgZtY1rHQ1x pdRLcwf8WoouY04Y+n+XQDHM3dThqli6BIhBX274C67lSaDYjZVV6odfZW6JURir /YszAMtrDtgaVGeew1q2XnqCZNuT4nNjVqWs6hd6yT3RJTQNeFOWYpmg4NXCg+q4 7y4XbOY9Mipt6NAAvcnpqM3MSV9zHWF7kBALBp14alZu/JtAixt+Y9kMzxv2z78/ QJJntW21l1CG8Fvjn0tGmOyL49eg8Qo1gskA4QbMtY4syT1U5twfZ3Q6KFMhhYE= =muiV -----END PGP SIGNATURE----- From Alexd at nominet.org.uk Thu Jan 21 12:01:34 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 21 Jan 2010 12:01:34 +0000 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <4B583F39.4030808@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> <983F17705339E24699AA251B458249B527EEEEFAA6@EXCHANGE2K7.office.nic.se> <4B583F39.4030808@nlnetlabs.nl> Message-ID: > >> Also, I got an error that the NAPTR record was not the same as in the > >> output zone, but I think is a false report from the auditor: > > > > That is fixed in r2687. The NAPTR in the test zone was not properly escaped. > > Yes, but even a bogus NAPTR record should be properly validated by the > auditor, imo. Yes, of course! This is a dnsruby issue which will be fixed once I return to the UK next week. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Thu Jan 21 13:30:27 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 21 Jan 2010 14:30:27 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <983F17705339E24699AA251B458249B527EEEEFAAE@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> <983F17705339E24699AA251B458249B527EEEEFAAE@EXCHANGE2K7.office.nic.se> Message-ID: <4B5856F3.7000007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Do all of the DNSKEYs need to be in the same RRset? Yes. And all these records should have the same TTL. > So the DNSKEY in the unsigned zone gets manipulated to have the same TTL as the ones created by OpenDNSSEC? I believe that is the correct thing to do. Matthijs Rickard Bellgrim wrote: > Do all of the DNSKEYs need to be in the same RRset? So the DNSKEY in the > unsigned zone gets manipulated to have the same TTL as the ones created > by OpenDNSSEC? > > // 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLWFbyAAoJEA8yVCPsQCW5S+0H/3uqa9Q5bLI9xDktTqNudGU7 3sSzLk8n2gebUJHH/2+KJ9bA182yk40Xpkvs5MF2LSvubl8QJZVzWxV6r2cxgA7I Q4ub0Hm6KS2o1Kj+EeRN36ApNVtvv0DAkSUkr8sIXqBzwGCU7aZG+hf8GEiEpOhy Y6hZpkHnbarzaQStaja0nMx9hcq+7TMfwM4+HXmWULupHAmxdK2LkDcUTMcX+g5M Ru5pBFDkprneC8PIlrg+QfTI6JSCmWKd1zMmJbKaLpX5Wgc+85diphuo1vVgRqfS XyVpvtuTNnbftE940o8YKBQrCRzZIWhZuP8sD7eQF9Jrmra4kdJNSyChtG9/Bik= =AM4W -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Jan 21 16:39:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 21 Jan 2010 16:39:27 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #74: acx_sqlite3.m4 requires sqlite3 command Message-ID: <065.d6eff42ce46b05d3bbac0df288b99775@kirei.se> #74: acx_sqlite3.m4 requires sqlite3 command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Hi, configure script requires (and AC_SUBSTs) sqlite3 command, which is then unused anywhere: $ grep -r SQLITE3 . | grep -Ev "(Makefile.in|configure(.ac)?|acx_sqlite3.m4):" ./config.h.in:#undef HAVE_LIBSQLITE3 ./config.h.in:#undef HAVE_SQLITE3_H ./src/lib/Makefile.am: @SQLITE3_INCLUDES@ ./src/lib/Makefile.am:libsofthsm_la_LIBADD = @BOTAN_LIBS@ @SQLITE3_LIBS@ @YIELD_LIB@ ./src/bin/Makefile.am: @SQLITE3_INCLUDES@ While it's not a problem to add sqlite3 as build-time dependency, I usually try to keep dependencies down as much as possible. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 21 17:44:01 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 21 Jan 2010 17:44:01 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable Message-ID: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- {{{ howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -a Checking C_Initialize and C_Finalize: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -b Checking C_GetInfo, C_GetFunctionList, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo, C_GetMechanismList, C_GetMechanismInfo: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -c Checking C_OpenSession, C_CloseSession, C_CloseAllSessions, and C_GetSessionInfo: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -d Checking C_Login and C_Logout: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -e Checking C_SeedRandom and C_GenerateRandom: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -f Segmentation fault howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -g Segmentation fault howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -i Checking C_DigestInit, C_Digest, C_DigestUpdate, and C_DigestFinal: OK howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -j Segmentation fault howl:/tmp/buildd/softhsm-1.1.2/checks# ./checks -k Segmentation fault howl:/tmp/buildd/softhsm-1.1.2/checks# }}} Backtrace: {{{ (gdb) run -f Starting program: /tmp/buildd/softhsm-1.1.2/checks/checks -f [Thread debugging using libthread_db enabled] [New Thread 0xf77e0b70 (LWP 6175)] [Thread 0xf77e0b70 (LWP 6175) exited] Program received signal SIGSEGV, Segmentation fault. 0xf7e0a925 in Botan::(anonymous namespace)::gmp_malloc(unsigned int) () from /usr/lib/libbotan-1.8.2.so Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 0xf7e0a925 in Botan::(anonymous namespace)::gmp_malloc(unsigned int) () from /usr/lib/libbotan-1.8.2.so #1 0xf783658f in __gmpz_init () from /usr/lib/libgmp.so.3 #2 0xf7e0c8a0 in Botan::GMP_MPZ::GMP_MPZ(Botan::BigInt const&) () from /usr/lib/libbotan-1.8.2.so #3 0xf7e0c338 in Botan::GMP_Engine::mod_exp(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) const () from /usr/lib/libbotan-1.8.2.so #4 0xf7e6a9c8 in Botan::Engine_Core::mod_exp(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) () from /usr/lib/libbotan-1.8.2.so #5 0xf7eae9ab in Botan::Power_Mod::set_modulus(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) const () from /usr/lib/libbotan-1.8.2.so #6 0xf7eaea72 in Botan::Power_Mod::Power_Mod(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) () from /usr/lib/libbotan-1.8.2.so #7 0xf7eaf251 in Botan::Fixed_Exponent_Power_Mod::Fixed_Exponent_Power_Mod(Botan::BigInt const&, Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) () from /usr/lib/libbotan-1.8.2.so #8 0xf7eac8d8 in Botan::MillerRabin_Test::MillerRabin_Test(Botan::BigInt const&) () from /usr/lib/libbotan-1.8.2.so #9 0xf7ead140 in Botan::passes_mr_tests(Botan::RandomNumberGenerator&, Botan::BigInt const&, unsigned int) () from /usr/lib/libbotan-1.8.2.so #10 0xf7ea8b77 in Botan::random_prime(Botan::RandomNumberGenerator&, unsigned int, Botan::BigInt const&, unsigned int, unsigned int) () from /usr/lib/libbotan-1.8.2.so #11 0xf7f31833 in Botan::RSA_PrivateKey::RSA_PrivateKey(Botan::RandomNumberGenerator&, unsigned int, unsigned int) () from /usr/lib/libbotan-1.8.2.so #12 0x08052df8 in rsaKeyGen (session=0x806d658, pPublicKeyTemplate=0xffffd708, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0xffffd6b4, ulPrivateKeyAttributeCount=7, phPublicKey=0xffffd78c, phPrivateKey=0xffffd788) at main.cpp:2247 #13 0x080531f8 in C_GenerateKeyPair (hSession=2, pMechanism=0xffffd778, pPublicKeyTemplate=0xffffd708, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0xffffd6b4, ulPrivateKeyAttributeCount=7, phPublicKey=0xffffd78c, phPrivateKey=0xffffd788) at main.cpp:2072 #14 0x0804e1cc in runGenerateCheck (counter=5) at checks.c:719 #15 0x08050ae4 in main (argc=2, argv=0xffffd864) at checks.c:94 }}} All other failed checks segfaults in same function C_GenerateKeyPair. Installed libraries: {{{ | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-===========================================-===========================================-====================================================================================================== ii libbotan-1.8.2 1.8.6-2 multiplatform crypto library ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:15:46 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:15:46 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #74: acx_sqlite3.m4 requires sqlite3 command In-Reply-To: <065.d6eff42ce46b05d3bbac0df288b99775@kirei.se> References: <065.d6eff42ce46b05d3bbac0df288b99775@kirei.se> Message-ID: <074.628b9ed47225e228aa7e46fd05422ade@kirei.se> #74: acx_sqlite3.m4 requires sqlite3 command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): True, SoftHSM does not require the binary. The acx_sqlite3.m4 is shared with OpenDNSSEC which do require the binary. So perhaps it would be a good idea to split the check for lib and binary. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:17:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:17:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.7d37611fb14102137282c5d6acf8ed71@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Hmm, haven't seen this one before. Usually the problem is with the version of Botan. But you use 1.8.6 which I have had no problem with. What if you upgrade to 1.8.8? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:21:52 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:21:52 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #76: Missing license headers Message-ID: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> #76: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: license ------------------------------------------+--------------------------------- Hi Alex, following files with code miss license headers: lib/kasp_checker.rb lib/time_shift.rb ods-auditor.in ods-kaspcheck.in Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:24:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:24:16 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #77: Redistributing trang without copying.txt violates copyright Message-ID: <065.4f2464004b67f42251d287c205fd3b37@kirei.se> #77: Redistributing trang without copying.txt violates copyright ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: critical | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Trang has 3-clause BSD license. Redistributing trang.jar without copying.txt violates first and second condition of the license: {{{ Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:32:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:32:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #77: Redistributing trang without copying.txt violates copyright In-Reply-To: <065.4f2464004b67f42251d287c205fd3b37@kirei.se> References: <065.4f2464004b67f42251d287c205fd3b37@kirei.se> Message-ID: <074.d12a3616f3a87480a538bdb54a5981c4@kirei.se> #77: Redistributing trang without copying.txt violates copyright ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: critical | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Changes (by jakob): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:32:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:32:07 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #78: Missing license headers Message-ID: <065.8b7c5dbdb78e7c588e9c03721888580c@kirei.se> #78: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- Hi following two files in libhsm misses license headers: src/compat/strlcat.h src/compat/strlcpy.h Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:32:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:32:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #76: Missing license headers In-Reply-To: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> References: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> Message-ID: <074.cadd3045cc05f4bf803441bcdb1fa627@kirei.se> #76: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: major | Component: Auditor Version: trunk | Keywords: license ------------------------------------------+--------------------------------- Changes (by jakob): * owner: alex => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:40:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:40:41 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #79: Use free pkcs11.h in libhsm Message-ID: <065.e8601ccb8f0bc89e96fa7ecbcc2a4324@kirei.se> #79: Use free pkcs11.h in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: minor | Component: libhsm Version: trunk | Keywords: ------------------------------------------+--------------------------------- Unfortunatelly pkcs11.h header files could not be considered as free due to advertising clause in the license. Please use pkcs11.h from SCUTE project which is drop-in replacement for 2.20 version of RSA header files. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 08:47:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 08:47:43 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.7ec310a7d9f6b1741bbd2e8161cbd722@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Hmm, looks like I will need to adopt botan1.8 since it has been orphaned by it's current maintainer :(. Will retry with 1.8.8 shortly. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 10:07:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 10:07:43 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #74: acx_sqlite3.m4 requires sqlite3 command In-Reply-To: <065.d6eff42ce46b05d3bbac0df288b99775@kirei.se> References: <065.d6eff42ce46b05d3bbac0df288b99775@kirei.se> Message-ID: <074.12e3681617d88ef1d37097db19bf6fac@kirei.se> #74: acx_sqlite3.m4 requires sqlite3 command ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: minor | Component: SoftHSM Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in r2694 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 10:18:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 10:18:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #76: Missing license headers In-Reply-To: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> References: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> Message-ID: <074.9a4cdb99ad7660db185e51943341430f@kirei.se> #76: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: major | Component: Auditor Version: trunk | Keywords: license ------------------------------------------+--------------------------------- Comment(by rb): Fixed in r2657 and r2695 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 10:19:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 10:19:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #76: Missing license headers In-Reply-To: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> References: <065.6ee7484fc2ac097beed75b751914194c@kirei.se> Message-ID: <074.f95b39a4a7d7422d9d19fc0383f7cd4c@kirei.se> #76: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: major | Component: Auditor Version: trunk | Resolution: fixed Keywords: license | ------------------------------------------+--------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 10:27:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 10:27:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #78: Missing license headers In-Reply-To: <065.8b7c5dbdb78e7c588e9c03721888580c@kirei.se> References: <065.8b7c5dbdb78e7c588e9c03721888580c@kirei.se> Message-ID: <074.7635837d11eec4eb3d14c82a5737c031@kirei.se> #78: Missing license headers ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: libhsm Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in r2696 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 11:42:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 11:42:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.46c267fe17abaa06773a8f7b3558a2eb@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): I have retried with botan 1.8.8 and it still segfaults, but with 1.8.8 the backtrace is slightly different (after recompiling with -O0): {{{ (gdb) run -f Starting program: /tmp/buildd/softhsm-1.1.2/checks/checks -f [Thread debugging using libthread_db enabled] [New Thread 0x7ffff5b45910 (LWP 13809)] [Thread 0x7ffff5b45910 (LWP 13809) exited] Program received signal SIGSEGV, Segmentation fault. memcpy () at ../sysdeps/x86_64/memcpy.S:103 103 ../sysdeps/x86_64/memcpy.S: No such file or directory. in ../sysdeps/x86_64/memcpy.S Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 memcpy () at ../sysdeps/x86_64/memcpy.S:103 #1 0x00007ffff7a4a687 in Botan::(anonymous namespace)::gmp_realloc(void*, unsigned long, unsigned long) () from /usr/lib/libbotan-1.8.2.so #2 0x00007ffff600035a in __gmpz_realloc () from /usr/lib/libgmp.so.3 #3 0x00007ffff5ff9650 in __gmpz_import () from /usr/lib/libgmp.so.3 #4 0x00007ffff7a4bf61 in Botan::GMP_MPZ::GMP_MPZ(Botan::BigInt const&) () from /usr/lib/libbotan-1.8.2.so #5 0x00007ffff7a4bb47 in Botan::GMP_Engine::mod_exp(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) const () from /usr/lib/libbotan-1.8.2.so #6 0x00007ffff7a8cce9 in Botan::Engine_Core::mod_exp(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) () from /usr/lib/libbotan-1.8.2.so #7 0x00007ffff7ac865a in Botan::Power_Mod::set_modulus(Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) const () from /usr/lib/libbotan-1.8.2.so #8 0x00007ffff7ac8839 in Botan::Fixed_Exponent_Power_Mod::Fixed_Exponent_Power_Mod(Botan::BigInt const&, Botan::BigInt const&, Botan::Power_Mod::Usage_Hints) () from /usr/lib/libbotan-1.8.2.so #9 0x00007ffff7ac6466 in Botan::MillerRabin_Test::MillerRabin_Test(Botan::BigInt const&) () from /usr/lib/libbotan-1.8.2.so #10 0x00007ffff7ac6900 in Botan::passes_mr_tests(Botan::RandomNumberGenerator&, Botan::BigInt const&, unsigned int) () from /usr/lib/libbotan-1.8.2.so #11 0x00007ffff7ac35a5 in Botan::random_prime(Botan::RandomNumberGenerator&, unsigned int, Botan::BigInt const&, unsigned int, unsigned int) () from /usr/lib/libbotan-1.8.2.so #12 0x00007ffff7b2c73f in Botan::RSA_PrivateKey::RSA_PrivateKey(Botan::RandomNumberGenerator&, unsigned int, unsigned int) () from /usr/lib/libbotan-1.8.2.so #13 0x000000000040d672 in rsaKeyGen (session=0x447af0, pPublicKeyTemplate=0x7fffffffe170, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0x7fffffffe0c0, ulPrivateKeyAttributeCount=7, phPublicKey=0x7fffffffdfa8, phPrivateKey=0x7fffffffdfa0) at main.cpp:2247 #14 0x000000000040d113 in C_GenerateKeyPair (hSession=2, pMechanism=0x7fffffffdf80, pPublicKeyTemplate=0x7fffffffe170, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0x7fffffffe0c0, ulPrivateKeyAttributeCount=7, phPublicKey=0x7fffffffdfa8, phPrivateKey=0x7fffffffdfa0) at main.cpp:2072 #15 0x0000000000406729 in runGenerateCheck (counter=5) at checks.c:719 #16 0x0000000000403f18 in main (argc=2, argv=0x7fffffffe338) at checks.c:94 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 12:01:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 12:01:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.4e46a12c878a02c4ec6f440510cff73e@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Could you also try to this in the Botan source: make check ./check --test I will also contact Jack Lloyd, the Botan developer, and see what he says. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 12:17:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 12:17:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.0faf30a7fc439216c0d2b518dab17df2@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): botan checks (./check --validate) are always run during a build process. I already wrote Jack :), when I announced that I'll be new Debian maintainer of botan. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 12:21:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 12:21:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #77: Redistributing trang without copying.txt violates copyright In-Reply-To: <065.4f2464004b67f42251d287c205fd3b37@kirei.se> References: <065.4f2464004b67f42251d287c205fd3b37@kirei.se> Message-ID: <074.26e3cbf13cb3685226cc4ca9d374761f@kirei.se> #77: Redistributing trang without copying.txt violates copyright ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: critical | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed Comment: Fixed in r2700. The copyright is now included when doing "make dist". Trang is only used at build time (to convert *.rnc to *.rng), so the copyright does not need to be included with the binaries. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 13:29:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 13:29:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.ff413580c0ba15a73a277b2b79a9a4c0@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): After some more debugging (linking with .a version of botan and gmp): There is something rotten in the kingdom of Denmark: softhsm compiled with -O2 backtrace: {{{ Program received signal SIGSEGV, Segmentation fault. memcpy () at ../sysdeps/x86_64/memcpy.S:102 102 ../sysdeps/x86_64/memcpy.S: No such file or directory. in ../sysdeps/x86_64/memcpy.S Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 memcpy () at ../sysdeps/x86_64/memcpy.S:102 #1 0x0000000000482252 in gmp_realloc (ptr=0x0, old_n=8, new_n=48) at src/engine/gnump/gmp_mem.cpp:35 #2 0x000000000053ff5b in __gmpz_realloc (m=0x64a208, new_alloc=6) at ../../mpz/realloc.c:51 #3 0x000000000053e0a0 in __gmpz_import (z=0x64a208, count=6, order=-1, size=8, endian=0, nail=0, data=0x643b90) at ../../mpz/import.c:50 #4 0x00000000004ff75b in GMP_MPZ (this=0x64a208, in=...) at src/engine/gnump/gmp_wrap.cpp:29 #5 0x00000000004ff299 in GMP_Modular_Exponentiator (this=0x64a1e0, n=...) at src/engine/gnump/gmp_powm.cpp:27 #6 0x00000000004ff409 in Botan::GMP_Engine::mod_exp (this=0x61e5b0, n=...) at src/engine/gnump/gmp_powm.cpp:50 #7 0x00000000005076a5 in Botan::Engine_Core::mod_exp (n=..., hints=260) at src/libstate/pk_engine.cpp:164 #8 0x00000000004ba251 in Botan::Power_Mod::set_modulus (this=0x7fffffffd740, n=..., hints=260) at src/math/numbertheory/pow_mod.cpp:58 #9 0x00000000004ba014 in Power_Mod (this=0x7fffffffd740, n=..., hints=260) at src/math/numbertheory/pow_mod.cpp:19 #10 0x00000000004baa7a in Fixed_Exponent_Power_Mod (this=0x7fffffffd740, e=..., n=..., hints=Botan::Power_Mod::NO_HINTS) at src/math/numbertheory/pow_mod.cpp:142 #11 0x00000000004b9bcf in MillerRabin_Test (this=0x7fffffffd7b0, num=...) at src/math/numbertheory/numthry.cpp:342 #12 0x00000000004b8a8c in Botan::passes_mr_tests (rng=..., n=..., level=1) at src/math/numbertheory/numthry.cpp:274 #13 0x00000000004b7307 in Botan::random_prime (rng=..., bits=384, coprime=..., equiv=1, modulo=2) at src/math/numbertheory/make_prm.cpp:75 #14 0x000000000044bedd in RSA_PrivateKey (this=0x6448f0, rng=..., bits=768, exp=65537, __in_chrg=, __vtt_parm=) at src/pubkey/rsa/rsa.cpp:68 #15 0x000000000040d5f9 in rsaKeyGen (session=, pPublicKeyTemplate=, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=, ulPrivateKeyAttributeCount=, phPublicKey=, phPrivateKey=0x7fffffffdf90) at main.cpp:2247 #16 0x000000000040d9f1 in C_GenerateKeyPair (hSession=, pMechanism=0x7fffffffdf70, pPublicKeyTemplate=0x7fffffffe160, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0x7fffffffe0b0, ulPrivateKeyAttributeCount=7, phPublicKey=0x7fffffffdf98, phPrivateKey=0x7fffffffdf90) at main.cpp:2072 #17 0x00000000004083b9 in runGenerateCheck (counter=5) at checks.c:719 #18 0x0000000000405ba8 in main (argc=2, argv=0x7fffffffe328) at checks.c:94 }}} softhsm compiled with -O0: {{{ (gdb) run -f Starting program: /tmp/buildd/softhsm-1.1.2/checks/checks -f [Thread debugging using libthread_db enabled] [New Thread 0x7ffff5c3f910 (LWP 27915)] [Thread 0x7ffff5c3f910 (LWP 27915) exited] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7dbce70 in vtable for Botan::Malloc_Allocator () from /usr/lib/libbotan-1.8.2.so (gdb) bt #0 0x00007ffff7dbce70 in vtable for Botan::Malloc_Allocator () from /usr/lib/libbotan-1.8.2.so #1 0x00007ffff7befc4d in gmp_malloc (n=8) at src/engine/gnump/gmp_mem.cpp:26 #2 0x00007ffff5e71688 in __gmpz_init () from /usr/lib/libgmp.so.3 #3 0x00007ffff7bf1805 in GMP_MPZ (this=0x44e2d8, in=...) at src/engine/gnump/gmp_wrap.cpp:27 #4 0x00007ffff7bf126d in GMP_Modular_Exponentiator (this=0x44e2d0, n=...) at src/engine/gnump/gmp_powm.cpp:27 #5 0x00007ffff7bf146d in Botan::GMP_Engine::mod_exp (this=0x4226a0, n=...) at src/engine/gnump/gmp_powm.cpp:50 #6 0x00007ffff7c3e32d in Botan::Engine_Core::mod_exp (n=..., hints=260) at src/libstate/pk_engine.cpp:164 #7 0x00007ffff7c798d5 in Botan::Power_Mod::set_modulus (this=0x7fffffffd700, n=..., hints=260) at src/math/numbertheory/pow_mod.cpp:58 #8 0x00007ffff7c79698 in Power_Mod (this=0x7fffffffd700, n=..., hints=260) at src/math/numbertheory/pow_mod.cpp:19 #9 0x00007ffff7c7a0fe in Fixed_Exponent_Power_Mod (this=0x7fffffffd700, e=..., n=..., hints=Botan::Power_Mod::NO_HINTS) at src/math/numbertheory/pow_mod.cpp:142 #10 0x00007ffff7c792ff in MillerRabin_Test (this=0x7fffffffd770, num=...) at src/math/numbertheory/numthry.cpp:342 #11 0x00007ffff7c781bc in Botan::passes_mr_tests (rng=..., n=..., level=1) at src/math/numbertheory/numthry.cpp:274 #12 0x00007ffff7c763ef in Botan::random_prime (rng=..., bits=384, coprime=..., equiv=1, modulo=2) at src/math/numbertheory/make_prm.cpp:75 #13 0x00007ffff7cd2999 in RSA_PrivateKey (this=0x4489e0, rng=..., bits=768, exp=65537, __in_chrg=, __vtt_parm=) at src/pubkey/rsa/rsa.cpp:68 #14 0x00007ffff7fe55ad in rsaKeyGen (session=0x42faf0, pPublicKeyTemplate=0x7fffffffe160, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0x7fffffffe0b0, ulPrivateKeyAttributeCount=7, phPublicKey=0x7fffffffdf98, phPrivateKey=0x7fffffffdf90) at main.cpp:2247 #15 0x00007ffff7fe5022 in C_GenerateKeyPair (hSession=2, pMechanism=0x7fffffffdf70, pPublicKeyTemplate=0x7fffffffe160, ulPublicKeyAttributeCount=6, pPrivateKeyTemplate=0x7fffffffe0b0, ulPrivateKeyAttributeCount=7, phPublicKey=0x7fffffffdf98, phPrivateKey=0x7fffffffdf90) at main.cpp:2072 #16 0x0000000000403e69 in runGenerateCheck (counter=5) at checks.c:719 #17 0x0000000000401658 in main (argc=2, argv=0x7fffffffe328) at checks.c:94 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 15:33:56 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 15:33:56 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> Message-ID: <067.26a89cdf0740c72921582a31c275c3c2@kirei.se> #71: Auditor blocks domain signing entirely ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: matthijs Type: defect | Status: assigned Priority: critical | Component: Signer Version: | Keywords: auditor deadlock ---------------------------------+------------------------------------------ Comment(by rb): Do we have a current status on this one? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 15:37:19 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 15:37:19 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #71: Auditor blocks domain signing entirely In-Reply-To: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> References: <058.f9c7b110cd0771a1cc86abd52261d700@kirei.se> Message-ID: <067.f8c3ad1c8b35fb0a221c1b5ff38007d2@kirei.se> #71: Auditor blocks domain signing entirely ---------------------------------+------------------------------------------ Reporter: rick@? | Owner: matthijs Type: defect | Status: closed Priority: critical | Component: Signer Version: | Resolution: worksforme Keywords: auditor deadlock | ---------------------------------+------------------------------------------ Changes (by vanrein): * status: assigned => closed * resolution: => worksforme Comment: As far as I am concerned, it falls in the category "too hard to reproduce" and it may have been an operational error on my end. Note that this is based on an earlier version, and we have seen similar blockings resolved since then. I say close it (and acted accordingly). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Jan 22 17:07:57 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 22 Jan 2010 17:07:57 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem Message-ID: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: blocker | Component: Unknown Version: trunk | Keywords: dnsruby ------------------------------------+--------------------------------------- Hello all, Now, when i want to install "dnsruby-1.41.gem", i have this error, and i think OpenDNSSEC is linked at "dnsruby"...perhaps an error (sorry). # gem install dnsruby-1.41.gem '''ERROR: While executing gem ... (NoMethodError) undefined method `include?' for nil:NilClass''' -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sat Jan 23 08:35:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 23 Jan 2010 08:35:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.ec8a81dd02d80a905c1c906cafc36174@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): I think you can retitle this bug to "Build depend on botan 1.8.9 (when it's out)". I have sent upstream patch provided by Jack to opendnssec- user, if anyone else is interested. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Jan 24 08:19:57 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 24 Jan 2010 08:19:57 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #81: [--signerconf ] --> (?) Message-ID: <061.44bb200444f89ab4cdf5be4550a3ef0e@kirei.se> #81: [--signerconf ] --> (?) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: signerconf.xml ------------------------------------+--------------------------------------- Hello, "ods-ksmutil" can be use this file, but there is no sample for this, and nothing too in your documentation... Best regards, it's just a notification for you. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Jan 24 12:30:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 24 Jan 2010 12:30:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #81: [--signerconf ] --> (?) In-Reply-To: <061.44bb200444f89ab4cdf5be4550a3ef0e@kirei.se> References: <061.44bb200444f89ab4cdf5be4550a3ef0e@kirei.se> Message-ID: <070.b901f0bab891039cc0f3137f87697315@kirei.se> #81: [--signerconf ] --> (?) ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: enhancement | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: wontfix Keywords: signerconf.xml | ------------------------------------+--------------------------------------- Changes (by jakob): * status: new => closed * resolution: => wontfix Comment: The signer configuration file is used internally in the inter-process communication between the KASP Enforcer and the Signer Engine - there are no user serviceable parts inside. The format is currently documented by its schema only. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Mon Jan 25 08:58:54 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 25 Jan 2010 08:58:54 +0000 Subject: [Opendnssec-develop] Audit tag in kasp.xml Message-ID: Morning. At some point during development we had the idea of the Audit tag in kasp.xml containing some extra XML that just got stored in the database. As far as I know this was never used, and the Audit tag is always either present and empty, or not present. Is this the case? If so I would like to remove the code that deals with exporting the XML for this tag as it is causing a segfault on some systems. Sion From jakob at kirei.se Mon Jan 25 09:01:30 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 25 Jan 2010 10:01:30 +0100 Subject: [Opendnssec-develop] Audit tag in kasp.xml In-Reply-To: References: Message-ID: <8054659C-A531-4B31-8310-215F457FA7D4@kirei.se> On 25 jan 2010, at 09.58, sion at nominet.org.uk wrote: > As far as I know this was never used, and the Audit tag is always either > present and empty, or not present. Is this the case? If so I would like to > remove the code that deals with exporting the XML for this tag as it is > causing a segfault on some systems. what we've said is that the Audit tag should be passed transparently from the policy to the signer, whether it is non-existing, empty or non-empty. for v1 we could settle for non-existing or empty, but we really should support the non-empty case as well if we can. jakob From sion at nominet.org.uk Mon Jan 25 09:06:40 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Mon, 25 Jan 2010 09:06:40 +0000 Subject: [Opendnssec-develop] Audit tag in kasp.xml In-Reply-To: <8054659C-A531-4B31-8310-215F457FA7D4@kirei.se> References: <8054659C-A531-4B31-8310-215F457FA7D4@kirei.se> Message-ID: > > As far as I know this was never used, and the Audit tag is always either > > present and empty, or not present. Is this the case? If so I would like to > > remove the code that deals with exporting the XML for this tag as it is > > causing a segfault on some systems. > > what we've said is that the Audit tag should be passed transparently > from the policy to the signer, whether it is non-existing, empty or non-empty. > for v1 we could settle for non-existing or empty, but we really > should support the non-empty case as well if we can. But does the signer or auditor do anything with the extra information? Sion From jakob at kirei.se Mon Jan 25 09:16:44 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 25 Jan 2010 10:16:44 +0100 Subject: [Opendnssec-develop] Audit tag in kasp.xml In-Reply-To: References: <8054659C-A531-4B31-8310-215F457FA7D4@kirei.se> Message-ID: <57ACD622-3FED-40CD-9238-BABD733309AC@kirei.se> On 25 jan 2010, at 10.06, sion at nominet.org.uk wrote: > But does the signer or auditor do anything with the extra information? for v1.0, no. jakob From owner-dnssec-trac at kirei.se Mon Jan 25 09:55:39 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 25 Jan 2010 09:55:39 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #75: softHSM checks segfaults in current Debian unstable In-Reply-To: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> References: <065.1926687b76ab79237f5f8aff7c15591a@kirei.se> Message-ID: <074.de00c0cd70fb5b642a2615152652e8c2@kirei.se> #75: softHSM checks segfaults in current Debian unstable ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: major | Component: SoftHSM Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Mon Jan 25 12:54:40 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 25 Jan 2010 13:54:40 +0100 Subject: [Opendnssec-develop] rc3 pending - please test trunk Message-ID: <664C20B7-79EE-40C7-9BD4-665338A1C818@kirei.se> hi, I'm planning to tag rc3 tonight some time after 20.00 CET (GMT+1). please do any late testing if you have time. jakob From Alexd at nominet.org.uk Mon Jan 25 13:29:44 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Mon, 25 Jan 2010 13:29:44 +0000 Subject: [Opendnssec-develop] rc3 pending - please test trunk In-Reply-To: <664C20B7-79EE-40C7-9BD4-665338A1C818@kirei.se> References: <664C20B7-79EE-40C7-9BD4-665338A1C818@kirei.se> Message-ID: Hi - > I'm planning to tag rc3 tonight some time after 20.00 CET (GMT+1). > please do any late testing if you have time. I've just got back from holiday, and have noticed that there are some signer changes which may require changes to the auditor. I'd like to take some time to test these, and potentially update the auditor. Can we please delay the rc3 tagging until I have had a chance to make these changes? This is unlikely to be today - maybe some time tomorrow? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Mon Jan 25 14:29:13 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 25 Jan 2010 15:29:13 +0100 Subject: [Opendnssec-develop] rc3 pending - please test trunk In-Reply-To: References: <664C20B7-79EE-40C7-9BD4-665338A1C818@kirei.se> Message-ID: <983F17705339E24699AA251B458249B527EEEEFEE9@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I've just got back from holiday, and have noticed that there are some > signer changes which may require changes to the auditor. I'd like to > take some time to test these, and potentially update the auditor. The changes had to do with making the TTL of any incoming DNSKEY the same as those we produce. And if there are different TTL:s in an RRset, then make them equal. The Auditor seems to accept the TTL:s differs between the unsigned and signed zone. > Can we please delay the rc3 tagging until I have had a chance to make > these changes? This is unlikely to be today - maybe some time tomorrow? So it looks like it is ok to release rc3 from my perspective. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS12queCjgaNTdVjaAQgI5wf+PDXgay+zjto5i4zPmzovQItZgk2yZNOp FF/1XVjlcUK1mDlI3HQzlhQqmWYRdUCqZtG3d6hJVYP+DD+RbNGD6T163WOtbif+ QVfcXyzmbTIf3RYmz0WOLgzb59Hw15UfcZ5kuxhgvxTvRcaowx7yicLlrN81+mUH 44eD8SHwPLt34WwMZX4xxEgGwztWERCgPHpOkxwJ3ZU0liR/k/yf7qTbZf0VWCm8 sJ2wNXnSKdKbU9feC5A9xEGYczrsAHZlVA4VO8CE/+GbI87/QrgTkErlnnZ8kl/L P/cVX6ck9cK2ol4EP7GcZ4Qr49t3pdmoy5JFr9zVDWpjzyvEVTGJag== =mPlD -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Jan 25 18:50:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 25 Jan 2010 18:50:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #82: Extra dependency on rubygems Message-ID: <065.bb808204d9c370131ee93606878b01ce@kirei.se> #82: Extra dependency on rubygems ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: enhancement | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Hi, auditor has dependency on rubygems, but it doesn't look like it need it at all. There is just one 'require', but it's not because auditor needs that, but because of dnsruby library. Could you please change that to optional dependency? Ie. look for dnsruby and if not found look for rubygems+dnsruby. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 08:43:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 08:43:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #79: Use free pkcs11.h in libhsm In-Reply-To: <065.e8601ccb8f0bc89e96fa7ecbcc2a4324@kirei.se> References: <065.e8601ccb8f0bc89e96fa7ecbcc2a4324@kirei.se> Message-ID: <074.3d7159a83ee0d708b39eb22912749aa8@kirei.se> #79: Use free pkcs11.h in libhsm ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: minor | Component: libhsm Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks Fixed in r2704 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 08:51:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 08:51:28 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION Message-ID: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- From configure.ac: AC_INIT([opendnssec-auditor], OPENDNSSEC_VERSION) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 08:58:33 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 08:58:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.719ad5cf2317d62aa2d5ddd44486190e@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by alex): alexs-macbook-pro-2:~ alex$ ods-auditor --version 1.0.0rc2-trunk ? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 09:00:20 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:00:20 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.332ae6fb51de33856bdf5059273d8aa0@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): OPENDNSSEC_VERSION is created by the main configure script. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 09:02:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:02:24 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #84: --version prints OPENDNSSEC_VERSION if you run autoreconf Message-ID: <065.05df7ea1f63639b118e7043287fdc43e@kirei.se> #84: --version prints OPENDNSSEC_VERSION if you run autoreconf ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- From configure.ac: AC_INIT([opendnssec-auditor], OPENDNSSEC_VERSION) So it looks like just a make dist problem, since configure file includes 1.0.0rc3. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 09:04:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:04:15 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #85: Please provide manpages Message-ID: <065.f44b4f339eff1d911e7e95ac5e5d6265@kirei.se> #85: Please provide manpages ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- I was able to create ods-auditor.1 from --help and comments, but I have not clue what ods-kaspcheck does, so it's just help2man output. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Jan 26 09:18:16 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 26 Jan 2010 10:18:16 +0100 Subject: [Opendnssec-develop] How to handle trunk until 1.0.0? Message-ID: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi We now have a RC3 and are really close to releasing 1.0.0. There are still coming in some suggested changes to the code and configure scripts. It would be reasonable to not commit any minor changes to trunk until we have released 1.0.0. But it would be ok to commit code if it fixes a major problem. If we decide to fix a problem, then we have to do a RC4. After 1.0.0 we have to decide on how to handle our release management, so that we do not get situations like this again. Do you agree? (Or do we want everything to be correct instead of releasing a 1.0.1 in a couple of weeks) // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS16zWOCjgaNTdVjaAQh/XQgAkvNf5waEk1Trz+M87KMVRkW8uojm2JP2 dg1qwGSVa6trmLh2OVmWssCN5ZG96KrtI545js6RMpO1cwVWHsHVxlZ1HcqXYXIs qrSHkfd8/f7ILhWeCWiMysDY82iYP98DjG5TcFvGNYNn4jO5Ma0+yyc4FnY8qEiY 7y47ITwaLFdbeK0bnZxboF610O6pD5dLksWygTVapHEh6tW1UrLXBWB+O/9n/0GL ivWAbKILc7Igy8O/wf7USI7dDQjN/naow8M+1DiqrHDVLzICNBVzBBAKidwwVpJ3 CXkpzO76F4g7AZKZbjTlzBY6KwSH2J9QWVlGet9FVksw270Vioghpg== =/SAh -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Tue Jan 26 09:21:44 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Tue, 26 Jan 2010 09:21:44 +0000 Subject: [Opendnssec-develop] How to handle trunk until 1.0.0? In-Reply-To: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> Message-ID: And there I was, just about to press the "commit" button on ticket #82 (removing rubygems from dependencies)... opendnssec-develop-bounces at lists.opendnssec.org wrote on 26/01/2010 09:18:16: > Rickard Bellgrim > Sent by: opendnssec-develop-bounces at lists.opendnssec.org > > 26/01/2010 09:18 > > To > > "Opendnssec-develop at lists.opendnssec.org" develop at lists.opendnssec.org> > > cc > > Subject > > [Opendnssec-develop] How to handle trunk until 1.0.0? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi > > We now have a RC3 and are really close to releasing 1.0.0. There are > still coming in some suggested changes to the code and configure > scripts. It would be reasonable to not commit any minor changes to > trunk until we have released 1.0.0. But it would be ok to commit > code if it fixes a major problem. > > If we decide to fix a problem, then we have to do a RC4. After 1.0.0 > we have to decide on how to handle our release management, so that > we do not get situations like this again. > > Do you agree? (Or do we want everything to be correct instead of > releasing a 1.0.1 in a couple of weeks) > > // Rickard > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBS16zWOCjgaNTdVjaAQh/XQgAkvNf5waEk1Trz+M87KMVRkW8uojm2JP2 > dg1qwGSVa6trmLh2OVmWssCN5ZG96KrtI545js6RMpO1cwVWHsHVxlZ1HcqXYXIs > qrSHkfd8/f7ILhWeCWiMysDY82iYP98DjG5TcFvGNYNn4jO5Ma0+yyc4FnY8qEiY > 7y47ITwaLFdbeK0bnZxboF610O6pD5dLksWygTVapHEh6tW1UrLXBWB+O/9n/0GL > ivWAbKILc7Igy8O/wf7USI7dDQjN/naow8M+1DiqrHDVLzICNBVzBBAKidwwVpJ3 > CXkpzO76F4g7AZKZbjTlzBY6KwSH2J9QWVlGet9FVksw270Vioghpg== > =/SAh > -----END PGP SIGNATURE----- > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Jan 26 09:30:19 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 26 Jan 2010 10:30:19 +0100 Subject: [Opendnssec-develop] How to handle trunk until 1.0.0? In-Reply-To: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> Message-ID: On 26 jan 2010, at 10.18, Rickard Bellgrim wrote: > We now have a RC3 and are really close to releasing 1.0.0. There are still coming in some suggested changes to the code and configure scripts. It would be reasonable to not commit any minor changes to trunk until we have released 1.0.0. But it would be ok to commit code if it fixes a major problem. > > If we decide to fix a problem, then we have to do a RC4. After 1.0.0 we have to decide on how to handle our release management, so that we do not get situations like this again. > > Do you agree? (Or do we want everything to be correct instead of releasing a 1.0.1 in a couple of weeks) we can branch 1.0 now or we wait until later. if we branch now, all changes to 1.0 needs to be fed back to trunk of course. jakob From owner-dnssec-trac at kirei.se Tue Jan 26 09:36:52 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:36:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #82: Extra dependency on rubygems In-Reply-To: <065.bb808204d9c370131ee93606878b01ce@kirei.se> References: <065.bb808204d9c370131ee93606878b01ce@kirei.se> Message-ID: <074.04f26c044ea2385362c2f16816d79334@kirei.se> #82: Extra dependency on rubygems ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: enhancement | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by alex): Ok - I have changes to fix this, but it looks like they will not be able to make the 1.0.0 release. I'll check them in when I can. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Tue Jan 26 09:38:58 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Tue, 26 Jan 2010 09:38:58 +0000 Subject: [Opendnssec-develop] How to handle trunk until 1.0.0? In-Reply-To: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> Message-ID: > We now have a RC3 and are really close to releasing 1.0.0. There are > still coming in some suggested changes to the code and configure > scripts. It would be reasonable to not commit any minor changes to > trunk until we have released 1.0.0. But it would be ok to commit > code if it fixes a major problem. > > If we decide to fix a problem, then we have to do a RC4. After 1.0.0 > we have to decide on how to handle our release management, so that > we do not get situations like this again. > > Do you agree? (Or do we want everything to be correct instead of > releasing a 1.0.1 in a couple of weeks) I think that anything that can't be fixed by some text in the KNOWN_ISSUES file means that we need an RC4. The image I had in my mind was that when 1.0.0 is released we branch; then bug fixes go into both branches and new features go into trunk only. Then, maybe when the KNOWN_ISSUES file is empty, we can release 1.0.1... Branching now just means that there is some merging to be done sooner (if RC3 doesn't become 1.0). Sion From owner-dnssec-trac at kirei.se Tue Jan 26 09:39:09 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:39:09 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem In-Reply-To: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> References: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> Message-ID: <070.49018d6a4d41af1548e47107876a16d2@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: blocker | Component: Unknown Version: trunk | Keywords: dnsruby ------------------------------------+--------------------------------------- Comment(by alex): Have you tried simply : gem install dnsruby ? The gem command will download the latest version of dnsruby automatically - no need for you to do that. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 09:41:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 09:41:27 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #83: --version prints OPENDNSSEC_VERSION In-Reply-To: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> References: <065.88d01dbfc55d6fe26fb54a44c4e8e380@kirei.se> Message-ID: <074.1a2f3ecbdfde20c91034f92a5a4a9b5a@kirei.se> #83: --version prints OPENDNSSEC_VERSION ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: minor | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Ok, so it's just problem, when you split main tarball into several smaller or you run autoreconf in auditor/ directory. I'll take this into account when repacking. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Jan 26 10:20:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 26 Jan 2010 11:20:39 +0100 Subject: [Opendnssec-develop] How to handle trunk until 1.0.0? In-Reply-To: References: <983F17705339E24699AA251B458249B527EEEF001F@EXCHANGE2K7.office.nic.se> Message-ID: <983F17705339E24699AA251B458249B527EEEF004C@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I think that anything that can't be fixed by some text in the > KNOWN_ISSUES > file means that we need an RC4. > > The image I had in my mind was that when 1.0.0 is released we branch; > then > bug fixes go into both branches and new features go into trunk only. > Then, > maybe when the KNOWN_ISSUES file is empty, we can release 1.0.1... > Branching now just means that there is some merging to be done sooner > (if > RC3 doesn't become 1.0). So what I am hearing is the we are leaning toward to branch when 1.0.0 is released and for now only write text to KNOWN_ISSUES. If the problem is major, then we need to do a RC4 (and other commits are then allowed before we do RC4). // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS17B9+CjgaNTdVjaAQgIEAf/XHaJh67SUH9OELY7cBUfHYPgjplyu3qf yEeNrfDIbFLSsckQZETvl+LCjM6yMY/BroZMF0Mazr8hLgCTSiSWYIqSO5e+GeMt ZgsVhVO4DmdV2qOL5zXAq6gVLkYO7s8WocJidRasA+S2lhYSUc1BamojMeNod3P7 VUJDfXa+mB+XDLB0rlQZwt0llVoiDLbhFGrjjacmXqgMkPDk2ZLCqymPeG4JnF2K ld8z1FpCh8WqRgrhMlMOv8H3iVUGwv0wHpmIdQxXRZglXsawehy3NtifwTTr1gZU 5/PPfK6JK9Ws3UFmIlGzIk9h+1VnnP1CW/kYLuEw2E0K4nhnqviJcQ== =SFub -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Tue Jan 26 10:27:45 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 26 Jan 2010 11:27:45 +0100 Subject: [Opendnssec-develop] List of HSM vendors Message-ID: <6D714BA4-B949-4124-986D-168F273C1EBD@kirei.se> ... now at http://www.opendnssec.org/documentation/hsm-vendors/. Contact me for updates. jakob From owner-dnssec-trac at kirei.se Tue Jan 26 10:28:44 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 10:28:44 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem In-Reply-To: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> References: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> Message-ID: <070.a7cc7559877011765f3d1f038128e28e@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: blocker | Component: Unknown Version: trunk | Keywords: dnsruby ------------------------------------+--------------------------------------- Comment(by rb): I usually install from dnsruby trunk, but now I tried to install using gem on Ubuntu 8.04. sudo gem install dnsruby Updating metadata for 1 gems from http://gems.rubyforge.org/ . complete ERROR: could not find dnsruby locally or in a repository -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 11:06:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 11:06:16 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #86: unclear licenses on m4/ files Message-ID: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Hi, sorry for being license fascist :), but there is lot unclear in m4/ directories. This applies to all components carrying those m4 files (including softhsm): acx_*.m4 - missing license header, license unclear acx_ruby_library.m4 - +header says acx_sqlite3.m4 (cut&paste) am_path_ruby.m4 - missing license header, illegal to distribute, since it's clearly modified python.m4 from GNU automake, which is licensed under: {{{ ## ------------------------ -*- Autoconf -*- ## Python file handling ## From Andrew Dalke ## Updated by James Henstridge ## ------------------------ # Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2008, 2009 # Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. }}} All other m4 files will be fine when license boilerplate will be added. am_ruby_path.m4 license will have to be fixed before it goes to Debian. Ondrej -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 11:15:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 11:15:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #86: unclear licenses on m4/ files In-Reply-To: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> References: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> Message-ID: <074.95071bf6a65cac240f4fd42db8b8c5b8@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by jakob): Putting a copyright on files like this seems just absurd. We don't put copyright on the autoconf files either and not on the READMEs. the resulting configure scripts seems to automatically be copyright FSF - which is absurd since it is a derived work based on the autoconf.ac file. Just say no to this nonsense. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 12:14:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 12:14:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #86: unclear licenses on m4/ files In-Reply-To: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> References: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> Message-ID: <074.0fca1be1795431aba19a5aebbdc78839@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): I'm fine with your own m4 files not having license boilerplate. Having LICENSE file in basedir would help though. But I will just assume that they are 2-clause BSD, copyright mixed (Nominet UK for auditor, enforcer, Nominet UK+.SE for libhsm, NLNet Labs for signer). But I'm not fine with taking python.m4 from automake, modifying it for ruby and dropping original license. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 12:23:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 12:23:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #86: unclear licenses on m4/ files In-Reply-To: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> References: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> Message-ID: <074.0864aa01f11785134f8fee788111dbe4@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by jakob): As far as I remember, am_path_ruby.m4 was copied from Prelude IDS. I'm note sure from were they got it and it is questionable whether it is copyrightable - the code contains lot of ruby-specific stuff. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 12:47:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 12:47:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem In-Reply-To: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> References: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> Message-ID: <070.9b485b6e5abda1ce5bbf2fc12dcdf51c@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: dnsruby ------------------------------------+--------------------------------------- Changes (by rb): * priority: blocker => trivial -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 14:35:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 14:35:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #86: unclear licenses on m4/ files In-Reply-To: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> References: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> Message-ID: <074.bde83e1fc92772dddbe929fff88c2598@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): This could be even more problematic, since Prelude IDS is GPLv2+. Anyway... to stop arguing this over and over - see attached am_prog_ruby.m4 written from scratch. You can include it in OpenDNSSEC and use whatever license you want to. You copy it to m4/ and do: {{{ -AM_PATH_RUBY([], [], []) +AM_PROG_RUBY() }}} in configure.ac -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 15:36:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 15:36:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 Message-ID: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Fix for cut&paste typo -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 15:44:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 15:44:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 In-Reply-To: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> References: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> Message-ID: <074.828a263d15955cf5b4d2b2132adbcc2b@kirei.se> #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Digged deeper - you can remove conf/m4/acx_pkcs11_modules.m4 But same typo is in libhsm/configure.ac (inline) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 16:23:42 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 16:23:42 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 In-Reply-To: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> References: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> Message-ID: <074.c8be480e14a7a833330832affa987591@kirei.se> #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Ah, just found that opendnssec-conf just doesn't use Alladin and OpenSC configure options, it will replace SoftHSM and SCA6000 paths in conf.xml.in. Anyway help text about "regression testing" in opendnssec-conf is little bit confusing. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 17:32:59 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 17:32:59 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem In-Reply-To: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> References: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> Message-ID: <070.2af84dd9173961667f17f62627ccb34b@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: dnsruby ------------------------------------+--------------------------------------- Comment(by archi.laurent@?): Replying to [comment:3 rb]: Hello all and thanks a lot for your answer : With Ubuntu 9.10, it's critical in automatic (1.39 !!!) gem install dnsruby Successfully installed dnsruby-1.39 --- i prefer with manual installation : And with this command gem is REDAY after : gem install rubygems-update-1.3.5.gem Best regards (it's closed forme) DNSRuby manual download is here : 1.41 or 1.42 and same gem too in another directory : http://rubyforge.org/frs/download.php/68000/dnsruby-1.41.gem -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 17:38:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 17:38:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #80: OpenDNSSEC + dnsruby-1.41.gem In-Reply-To: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> References: <061.424953c1c47a95d8213f4ad958f58adc@kirei.se> Message-ID: <070.8183407f6ec1fcc1a00c0273f43e29e9@kirei.se> #80: OpenDNSSEC + dnsruby-1.41.gem ------------------------------------+--------------------------------------- Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: worksforme Keywords: dnsruby | ------------------------------------+--------------------------------------- Changes (by alex): * status: new => closed * resolution: => worksforme -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 18:41:58 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 18:41:58 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #86: unclear licenses on m4/ files In-Reply-To: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> References: <065.c8dd66ef10bb7f120b5256f59d6187d7@kirei.se> Message-ID: <074.81916d84a90b489c0cbe9b0f21ef462e@kirei.se> #86: unclear licenses on m4/ files ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: closed Priority: major | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jakob): * status: new => closed * resolution: => fixed Comment: Thanks a lot! Committed as r2723. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 26 18:57:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 26 Jan 2010 18:57:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 In-Reply-To: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> References: <065.b348c042d8cc7068c1025c9b91f94b25@kirei.se> Message-ID: <074.63cfc1df0ea188003c60b9961e41c5fd@kirei.se> #87: s/Alladin/OpenSC/ in acx_pkcs11_modules.m4 ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jakob): * status: new => closed * resolution: => fixed Comment: Thanks, fixed and clarified in r2726. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 27 09:41:21 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 27 Jan 2010 09:41:21 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #88: Race condition in key backup? Message-ID: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: --------------------+------------------------------------------------------- If I read the documentation correctly, there is a race condition in the manual key backup procedure. While I am doing a backup, keys may still be generated automatically by OpenDNSSEC. This makes it difficult to decide when I should submit the "ods-ksmutil backup done" command? If I submit the command before making the backup, I would initiate the use of keys that haven't been backed up yet. But if I submit the command after making the backup, I could have missed backing up a key that just got created, and again, cause it to be used before it is backed up. I don't know if/how the key generation can be stopped during the backup procedure. Also, using "ksmutil backup list" does not reveal the number of keys standing by for backup so I could verify that none got added, nor does "ksmutil backup done" tell me how many keys have been marked fit-for- use, let alone that it would have me constrain how many it could mark fit- for-use. Ideally, backups would be a 2-phase procedure, but a work-around could be anything that ensures that no keys were generated since the backup started. Is there a way we can document how to avoid this race condition by following a (slightly more complicated) procedure, so DNS administrators can be absolutely certain that all the keys in use have been backed up if is used? -- Ticket URL: OpenDNSSEC OpenDNSSEC From marco.davids at sidn.nl Wed Jan 27 11:06:42 2010 From: marco.davids at sidn.nl (Marco Davids) Date: Wed, 27 Jan 2010 12:06:42 +0100 Subject: [Opendnssec-develop] Bug in logging.c ? Message-ID: <4B601E42.9050500@sidn.nl> Hi there, It seems to me that there is a bug in the 'facility2int' function in logging.c. else if (strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) *fac = LOG_LOCAL0; and all the other ones in that same statement seem to have the wrong effect. When 'dup' is 'LOCAL0', the return value of strncmp is zero, hence the if-statement will fail, where it was suppose to be succesful, How about this? else if (strncmp(dup, "LOCAL0", 6) == 0 && strlen(dup) == 6) *fac = LOG_LOCAL0; Or else if (! strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) *fac = LOG_LOCAL0; Cheers, -- Marco Davids SIDN From Alexd at nominet.org.uk Wed Jan 27 11:08:15 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 27 Jan 2010 11:08:15 +0000 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <4B58371B.2080404@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> Message-ID: Hi - > Also, I got an error that the NAPTR record was not the same as in the > output zone, but I think is a false report from the auditor: > > Input: > > all.rr.binary.org. IN NAPTR 100 10 "" "" > "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . > > Output (.finalized): > > all.rr.binary.org. IN NAPTR 100 10 "" "" > "/urn:cid:.+@([^.]+.)(.*)$/2/i" . > Should output not actually be : all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@( [^.]+.)(.*)$/\002/i" . or all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@([^.]+.)(.*)$/\2/i" . ? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Wed Jan 27 11:15:02 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 27 Jan 2010 12:15:02 +0100 Subject: [Opendnssec-develop] Bug in logging.c ? In-Reply-To: <4B601E42.9050500@sidn.nl> References: <4B601E42.9050500@sidn.nl> Message-ID: <4B602036.50808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Absolutely right. Thanks, Matthijs Marco Davids wrote: > Hi there, > > It seems to me that there is a bug in the 'facility2int' function in > logging.c. > > else if (strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) > *fac = LOG_LOCAL0; > > and all the other ones in that same statement seem to have the wrong > effect. When 'dup' is 'LOCAL0', the return value of strncmp is zero, > hence the if-statement will fail, where it was suppose to be succesful, > > How about this? > > else if (strncmp(dup, "LOCAL0", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL0; > > Or > > else if (! strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) > *fac = LOG_LOCAL0; > > Cheers, > > -- > Marco Davids > SIDN > > > _______________________________________________ > 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLYCA0AAoJEA8yVCPsQCW5CcIH/i4Ib5NFAk5ygsUcDG3tSIxq dHTuE9rQftdLmnFiMor3bfr4cbTEjCON1iy5257AwJVyKA4lgxIoweRvSii3UMdP MiEdtX3WI30qTv8m4bY/zCkSrSNyiU3aPw8jjwjJz2guV78k85spntzHhBqGG768 2k7U0nlWbqxM+/n915XxpkrfoD2toC1/tn4rezNDYDUKkJhNFv4bTW/EDAv/a9ZF 2QvJcYpjQPDVG3BMHrApUmV78pMCy1hivZy03u0wsaDsIOlqPc10wH72BVehRDhz yceYMs4eqVCPnVjBtMFDvtC5orWvLhY+L0/BkhZN6Bd8vstwN8GfE/avvaPbpMQ= =foTB -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Wed Jan 27 11:27:53 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 27 Jan 2010 12:27:53 +0100 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> Message-ID: <4B602339.1000606@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I parse "\2" as an escape character followed by a 2. I need to take that 2 literally. So I need to put a '2' in the buffer. The escape character was not useful, as it is equal to the character string "2". Now take "\002". This is what I believe is a octal value. This is not equal to "\2". To be honest, RFC 1035 does say: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. So, how to handle \X where X is a digit? 1. \X -> 'X' 2. \X -> '\' 'X' Matthijs Alexd at nominet.org.uk wrote: > Hi - > >> Also, I got an error that the NAPTR record was not the same as in the >> output zone, but I think is a false report from the auditor: >> >> Input: >> >> all.rr.binary.org. IN NAPTR 100 10 "" "" >> "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . >> >> Output (.finalized): >> >> all.rr.binary.org. IN NAPTR 100 10 "" "" >> "/urn:cid:.+@([^.]+.)(.*)$/2/i" . >> > > Should output not actually be : > > all.rr.binary.org. IN NAPTR 100 10 "" "" > "/urn:cid:.+@([^.]+.)(.*)$/\002/i" . > > or > > all.rr.binary.org. IN NAPTR 100 10 "" "" "/urn:cid:.+@([^.]+.)(.*)$/\2/i" . > > ? > > Thanks, > > > Alex. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLYCM0AAoJEA8yVCPsQCW55bEIAI/r9FcsyK+pTXV98bkp6N3I 4jnQIGLYGBGMDa2XSzbWgwbmFv4K+LKW2epCSx1KNBRWQrhjCAo2A10cw4maQa3l 1m27q6sfuZZ5tTg5xuKmaTW+RZJYFNtWsHvWr9tdqgA+CLZ1uYdf8OlYPiCSsFkZ efcix48IfWtrLRCM/LZLhh3oLqiKeIFSOftuNTfFtgU5HVH9JAdNcQwGeFiSTubz s8qw/NhJWWyertWZjHEV1MhYkH3jRmhCc/Y2nyNx/fXUp4Fa6s+1p0g5YtJoonTa n2aw5Lmkrn2TQwsm8sVMNtg7Jkp4sv1YGXwNI2ZbvkBjdv2dw1pyXCMpus119DE= =n+Ja -----END PGP SIGNATURE----- From marco.davids at sidn.nl Wed Jan 27 11:27:17 2010 From: marco.davids at sidn.nl (Marco Davids) Date: Wed, 27 Jan 2010 12:27:17 +0100 Subject: [Opendnssec-develop] Zonefetch.xml Message-ID: <4B602315.2030608@sidn.nl> Peoples, May I suggest to add 'IPv4' or 'IPv6' to the zonefetch.xml example? like in: 192.0.2.10053 It may save others the trouble of digging in the XML-schema like I did and thus save them some time while settings things up :-) Cheers, -- Marco From Alexd at nominet.org.uk Wed Jan 27 11:32:28 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Wed, 27 Jan 2010 11:32:28 +0000 Subject: [Opendnssec-develop] Testing for RC3, found a new zone to test with In-Reply-To: <4B602339.1000606@nlnetlabs.nl> References: <983F17705339E24699AA251B458249B527EEEEFA18@EXCHANGE2K7.office.nic.se> <4B58371B.2080404@nlnetlabs.nl> <4B602339.1000606@nlnetlabs.nl> Message-ID: > To be honest, RFC 1035 does say: > > \X where X is any character other than a digit (0-9), is > used to quote that character so that its special meaning > does not apply. For example, "\." can be used to place > a dot character in a label. > > So, how to handle \X where X is a digit? This is the nub of my question. > 1. \X -> 'X' > 2. \X -> '\' 'X' I don't think that "\X" where X is a digit, is legal according to RFC1035 5.1. I think it should be removed from the test for this story. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Wed Jan 27 12:06:34 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 27 Jan 2010 13:06:34 +0100 Subject: [Opendnssec-develop] gmane Message-ID: <5E5FA4C5-DFEA-4FDA-86EC-4EA3E1E42E25@iis.se> Do we want to add our mailinglists to gmane? http://gmane.org/subscribe.php -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From rick.zijlker at sidn.nl Wed Jan 27 12:07:22 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Wed, 27 Jan 2010 13:07:22 +0100 Subject: [Opendnssec-develop] Unused policies Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A0@KAEVS1.SIDN.local> Hey all, When you have several policies in your kasp.xml and not using the 'default' policy in any of the zones in the zonelist, what happens with these unused policies, including the default? I keep getting warnings and messages about the default policy at every resign even though I'm not using it. I would assume it's not logical to be checking all (unused) policies during a resign of one specific policy. Slows things down. In my case I kept getting messages about a full repository, even though I'm not even using that repo. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Jan 27 12:17:28 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 27 Jan 2010 13:17:28 +0100 Subject: [Opendnssec-develop] gmane In-Reply-To: <5E5FA4C5-DFEA-4FDA-86EC-4EA3E1E42E25@iis.se> References: <5E5FA4C5-DFEA-4FDA-86EC-4EA3E1E42E25@iis.se> Message-ID: <3FC3CA9C-C71F-42C7-B279-A1210D7871DA@kirei.se> On 27 jan 2010, at 13.06, Patrik Wallstr?m wrote: > Do we want to add our mailinglists to gmane? > http://gmane.org/subscribe.php sure. why not? jakob From owner-dnssec-trac at kirei.se Wed Jan 27 13:01:01 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 27 Jan 2010 13:01:01 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #89: bug in logging.c Message-ID: <045.18c2dcb1e90b23f9f1f7008e4d87142b@kirei.se> #89: bug in logging.c --------------------+------------------------------------------------------- Reporter: mdavids | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: --------------------+------------------------------------------------------- There is a bug in the 'facility2int' function in logging.c. else if (strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) *fac = LOG_LOCAL0; and all the other ones in that same statement seem to have the wrong effect. When 'dup' is 'LOCAL0', the return value of strncmp is zero, hence the if-statement will fail, where it was suppose to be succesful, Solution: else if (strncmp(dup, "LOCAL0", 6) == 0 && strlen(dup) == 6) *fac = LOG_LOCAL0; Or else if (! strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) *fac = LOG_LOCAL0; -- Marco Davids -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed Jan 27 13:07:38 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Wed, 27 Jan 2010 13:07:38 +0000 Subject: [Opendnssec-develop] Unused policies In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A0@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86A0@KAEVS1.SIDN.local> Message-ID: > Hey all, > > When you have several policies in your kasp.xml and not using the > ?default? policy in any of the zones in the zonelist, what happens > with these unused policies, including the default? I keep getting > warnings and messages about the default policy at every resign even > though I?m not using it. I would assume it?s not logical to be > checking all (unused) policies during a resign of one specific > policy. Slows things down. Just to clarify, this will be happening when the enforcer runs, not on resigning. > In my case I kept getting messages about a full repository, even > though I?m not even using that repo. We have a story (in the icebox at the moment) about removing policies completely. If I also add a story about not checking repo capacity if no keys need to be generated then I think that we are covered? You can minimise the amount of work done for an unused policy by setting the ManualKeyGeneration tag; which I appreciate is not a long term solution. Sion From owner-dnssec-trac at kirei.se Wed Jan 27 13:45:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 27 Jan 2010 13:45:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #88: Race condition in key backup? In-Reply-To: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> References: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> Message-ID: <054.bcc205908e10e2558bebddc620f2e51b@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: --------------------+------------------------------------------------------- Comment(by rb): A 2-phase procedure would be good to have, so that you do not get a race condition. We shall discuss this tomorrow whether the fix should go into 1.0.0 or later. -- Ticket URL: OpenDNSSEC OpenDNSSEC From Antoin.Verschuren at sidn.nl Wed Jan 27 14:15:46 2010 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 27 Jan 2010 15:15:46 +0100 Subject: [Opendnssec-develop] Empty non terminals: 212 unjustified NSEC3s in .nl zone Message-ID: <850A39016FA57A4887C0AA3C8085F949019C6703@KAEVS1.SIDN.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Guys, We may have found one of the reasons why signing .nl is slow. There are 212 delegations in our zone with corresponding glue which have the following form in our .nl zone: $ORIGIN nl. telemena NS a.ns.telemena NS b.ns.telemena $ORIGIN ns.telemena.nl. a A 81.171.4.1 b A 81.171.1.3 The signer sees these delegations and glue as empty non terminals, and NSEC3s the data. [root at signer2 tmp]# grep telemena nl.signed ; Empty non-terminal: ns.telemena.nl. ; Glue: b.ns.telemena.nl. 7200 IN A 81.171.1.3 telemena.nl. 7200 IN NS a.ns.telemena.nl. telemena.nl. 7200 IN NS b.ns.telemena.nl. ; Glue: a.ns.telemena.nl. 7200 IN A 81.171.4.1 So instead of the expected 10 RRSIGs, we now suddenly have 212 more NSEC3, and 4 times that much RRSIG records when using opt-out. Is there another way to speed this up ? Signing a fresh .nl now takes 50 minutes with NSEC3 and opt-out. Bind 9.7 does not NSEC3 the empty non-terminals, and we only get 8 NSEC3 records. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBS2BKkjqHrM883AgnAQijbgf/UvbIW28O3c833xRxrxQspP5MikPrED5h zUUkzsolvJrxttNSjUQuQa2qYRStht915hMjm3oXELqY+BwNtWRTLrD8ZNRRXqGc JzeXH3JnXsZ4ImwiKlRJXQMEWRwHGPkMrWJOgpzIEjNQfQVv1agyfVaQaW9zRuMk eu+s06QNGOSXNGr7dRyIUsa+nWMRIzwRMBaCOxfWPc8BqY43kgHR32/ph4PNwWrx fa/9Wjk9SmVCGjNdDiH3X9ytHd9jQ7NDcyoGRaCtOZShxjjsR+E+/gtZMCOuSCrm I7UF4ZIm0XPXGbtk0HcTv1LRn1zLTj5v7mZBqZeJVR9QKUyFX/PAtA== =GJGm -----END PGP SIGNATURE----- From roy at nominet.org.uk Wed Jan 27 14:24:00 2010 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 27 Jan 2010 09:24:00 -0500 Subject: [Opendnssec-develop] Empty non terminals: 212 unjustified NSEC3s in .nl zone In-Reply-To: <850A39016FA57A4887C0AA3C8085F949019C6703@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949019C6703@KAEVS1.SIDN.local> Message-ID: Antoin Verschuren wrote on 01/27/2010 09:15:46 AM: > Hi Guys, > > We may have found one of the reasons why signing .nl is slow. > There are 212 delegations in our zone with corresponding glue which > have the following form in our .nl zone: > > $ORIGIN nl. > telemena NS a.ns.telemena > NS b.ns.telemena > $ORIGIN ns.telemena.nl. > a A 81.171.4.1 > b A 81.171.1.3 > > The signer sees these delegations and glue as empty non terminals, > and NSEC3s the data. That's indeed superfluous. It doesn't actually hurt in a protocol sense, but it influences performance negatively. This needs to be fixed. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Wed Jan 27 15:47:02 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 27 Jan 2010 16:47:02 +0100 Subject: [Opendnssec-develop] Test the new sorter Message-ID: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi There is a new sorter available in our SVN. Could you test it if you had any performance issues, e.g. SIDN? Solves some part of the problem. wget http://trac.opendnssec.org/export/2729/home/bjst/quicksorter.c gcc -Wall quicksorter.c -o quicksorter time ./quicksorter -f -w -m -t -o Compare the result with time /usr/local/libexec/opendnssec/sorter -f -w -m -t -o It is 10 times faster for me. // Rickard -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBS2Bf9uCjgaNTdVjaAQiOEQf/QtwEZINZKNPmApEKsXCDFTP+8Jz6UOAq 5AmkcNDjaz47hrdv+/voBPNu+CFws1Hw200gKysXk/rnkU848v+29o0iLv2p0TW5 9GAGVYJM5CQHcXRCQDB6B0/bb8IARbeokWHv2IGoGbk+ALcr+Dh4010mfuFGh7C8 nV57pYGNvf/rnpnmryEFP0xPqSBac5PsblVjABg/Hr6o0cKpPC1tR5tVqwjxoEDj pVzvQxz2v7oq8bl0OkpAlqZ0xT/cp6KZG+hBdrh4wxzbY1LdyoicLIGYg7G11NpW 3IYdr46p/ZYVY+E+TC6C1AIjZU8sZBBL15qJ0YBgglK0dObR55PyEA== =d0Ce -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Wed Jan 27 15:58:01 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 27 Jan 2010 15:58:01 +0000 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> Message-ID: <20100127155801.GG9808@phantom.vanrein.org> Hello, > There is a new sorter available in our SVN. Could you test it if you had any performance issues, e.g. SIDN? Solves some part of the problem. > > wget http://trac.opendnssec.org/export/2729/home/bjst/quicksorter.c > gcc -Wall quicksorter.c -o quicksorter But wait... this relies on QuickSort...? QuickSort *averages* on O(n.log(n)) complexity, but it can be as bad as O(n^2) in bad cases such as sorting an already sorted list. It is more reliable to use HeapSort which always has O(n.log(n)) behaviour. http://en.wikipedia.org/wiki/Quicksort http://en.wikipedia.org/wiki/Heapsort If you want to have the best of both worlds, you'd use IntroSort. http://en.wikipedia.org/wiki/Introsort Sorry I didn't mention this before -- I thought everybody knew. Cheers, -Rick From roy at nominet.org.uk Wed Jan 27 16:23:40 2010 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 27 Jan 2010 11:23:40 -0500 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <20100127155801.GG9808@phantom.vanrein.org> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <20100127155801.GG9808@phantom.vanrein.org> Message-ID: Rick van Rein wrote on 01/27/2010 10:58:01 AM: > Hello, > > > There is a new sorter available in our SVN. Could you test it if > you had any performance issues, e.g. SIDN? Solves some part of the problem. > > > > wget http://trac.opendnssec.org/export/2729/home/bjst/quicksorter.c > > gcc -Wall quicksorter.c -o quicksorter > > But wait... this relies on QuickSort...? > > QuickSort *averages* on O(n.log(n)) complexity, but it can > be as bad as O(n^2) in bad cases such as sorting an already > sorted list. It is more reliable to use HeapSort which always > has O(n.log(n)) behaviour. Qsort in stdlib uses median selection to avoid O(n^2). Heapsort is _slower_ than qsort. Introsort in not in any standard lib. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at haxx.se Wed Jan 27 16:27:36 2010 From: bjorn at haxx.se (=?iso-8859-1?Q?Bj=F6rn?= Stenberg) Date: Wed, 27 Jan 2010 17:27:36 +0100 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: <20100127155801.GG9808@phantom.vanrein.org> References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <20100127155801.GG9808@phantom.vanrein.org> Message-ID: <20100127162736.GE2329@giant> Rick van Rein wrote: > But wait... this relies on QuickSort...? No, it relies on the qsort() function of your C library. The program is called "quicksorter" merely because it intends to do the same job as signer/tools/sorter, only quicker. Feel free to test with specific algorithms. I did a quick test run with a BSD heapsort[1] and it was four times slower than qsort() on my machine. [1] http://www.koders.com/c/fid331771A765F04207384419D44D95D19CE4D3CCA7.aspx -- Bj?rn From rick at openfortress.nl Wed Jan 27 17:17:52 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 27 Jan 2010 17:17:52 +0000 Subject: [Opendnssec-develop] Test the new sorter In-Reply-To: References: <983F17705339E24699AA251B458249B527EEEF03C7@EXCHANGE2K7.office.nic.se> <20100127155801.GG9808@phantom.vanrein.org> Message-ID: <20100127171752.GA12122@phantom.vanrein.org> Hi, > Qsort in stdlib uses median selection to avoid O(n^2). Heapsort is > _slower_ than qsort. Introsort in not in any standard lib. Ah, thanks, I didn't know that. That ought to suffice to make sorting reliably fast, which is important for large zones. Cheers, -Rick From owner-dnssec-trac at kirei.se Thu Jan 28 09:43:38 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 28 Jan 2010 09:43:38 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #89: bug in logging.c In-Reply-To: <045.18c2dcb1e90b23f9f1f7008e4d87142b@kirei.se> References: <045.18c2dcb1e90b23f9f1f7008e4d87142b@kirei.se> Message-ID: <054.1f07e1cd99a0e710fe890c69b72d0270@kirei.se> #89: bug in logging.c --------------------+------------------------------------------------------- Reporter: mdavids | Owner: rb Type: defect | Status: closed Priority: minor | Component: Unknown Version: trunk | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: In trunk -- Ticket URL: OpenDNSSEC OpenDNSSEC From Alexd at nominet.org.uk Thu Jan 28 09:46:16 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 28 Jan 2010 09:46:16 +0000 Subject: [Opendnssec-develop] Fw: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2731 - in trunk/OpenDNSSEC: . conf signer/tools Message-ID: Hi - Is trunk open for minor fixes? I thought we were freezing all OpenDNSSEC changes until 1.0.0 release? Or else committing to a 1.0.0RC4 release? Thanks, Alex. ----- Forwarded by Alex Dalitz/Nominet on 28/01/2010 09:45 ----- opendnssec-commits-bounces at lists.opendnssec.org wrote on 28/01/2010 09:43:12: > "Matthijs Mekking" > Sent by: opendnssec-commits-bounces at lists.opendnssec.org > > 28/01/2010 09:43 > > To > > undisclosed-recipients: ; > > cc > > Subject > > [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2731 - in > trunk/OpenDNSSEC: . conf signer/tools > > Author: matthijs > Date: 2010-01-28 10:43:12 +0100 (Thu, 28 Jan 2010) > New Revision: 2731 > > Modified: > trunk/OpenDNSSEC/NEWS > trunk/OpenDNSSEC/conf/zonefetch.xml.in > trunk/OpenDNSSEC/signer/tools/logging.c > trunk/OpenDNSSEC/signer/tools/sorter.c > Log: > bug 89 > > zonefetch example comment > > > > Modified: trunk/OpenDNSSEC/NEWS > =================================================================== > --- trunk/OpenDNSSEC/NEWS 2010-01-27 15:49:33 UTC (rev 2730) > +++ trunk/OpenDNSSEC/NEWS 2010-01-28 09:43:12 UTC (rev 2731) > @@ -2,7 +2,7 @@ > > OpenDNSSEC trunk > > -* ... > +* Bugreport #89: Signer Engine: bug in logging.c. > > > OpenDNSSEC 1.0.0rc3 - 2010-01-25 > > Modified: trunk/OpenDNSSEC/conf/zonefetch.xml.in > =================================================================== > --- trunk/OpenDNSSEC/conf/zonefetch.xml.in 2010-01-27 15:49:33 UTC(rev 2730) > +++ trunk/OpenDNSSEC/conf/zonefetch.xml.in 2010-01-28 09:43:12 UTC(rev 2731) > @@ -7,6 +7,13 @@ > > 53 > > + > + > + > > > > Modified: trunk/OpenDNSSEC/signer/tools/logging.c > =================================================================== > --- trunk/OpenDNSSEC/signer/tools/logging.c 2010-01-27 15:49:33 > UTC (rev 2730) > +++ trunk/OpenDNSSEC/signer/tools/logging.c 2010-01-28 09:43:12 > UTC (rev 2731) > @@ -52,12 +52,7 @@ > static void > log_vmsg(int priority, const char* s, va_list args) > { > - char message[ODD_MAXLEN]; > - > - vsnprintf(message, sizeof(message), s, args); > - > - if (logging_to_syslog) > - syslog(priority, "%s", message); > + vsyslog(priority, s, args); > } > > void > @@ -97,55 +92,55 @@ > } > strtoupper(dup); > > - if (strncmp(dup, "USER", 4) && strlen(dup) == 4) > + if (strncmp(dup, "USER", 4) == 0 && strlen(dup) == 4) > *fac = LOG_USER; > #ifdef LOG_KERN > - else if (strncmp(dup, "KERN", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "KERN", 4) == 0 && strlen(dup) == 4) > *fac = LOG_KERN; > #endif > #ifdef LOG_MAIL > - else if (strncmp(dup, "MAIL", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "MAIL", 4) == 0 && strlen(dup) == 4) > *fac = LOG_MAIL; > #endif > #ifdef LOG_DAEMON > - else if (strncmp(dup, "DAEMON", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "DAEMON", 6) == 0 && strlen(dup) == 6) > *fac = LOG_DAEMON; > #endif > #ifdef LOG_AUTH > - else if (strncmp(dup, "AUTH", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "AUTH", 4) == 0 && strlen(dup) == 4) > *fac = LOG_AUTH; > #endif > #ifdef LOG_LPR > - else if (strncmp(dup, "LPR", 3) && strlen(dup) == 3) > + else if (strncmp(dup, "LPR", 3) == 0 && strlen(dup) == 3) > *fac = LOG_LPR; > #endif > #ifdef LOG_NEWS > - else if (strncmp(dup, "NEWS", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "NEWS", 4) == 0 && strlen(dup) == 4) > *fac = LOG_NEWS; > #endif > #ifdef LOG_UUCP > - else if (strncmp(dup, "UUCP", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "UUCP", 4) == 0 && strlen(dup) == 4) > *fac = LOG_UUCP; > #endif > #ifdef LOG_CRON > - else if (strncmp(dup, "CRON", 4) && strlen(dup) == 4) > + else if (strncmp(dup, "CRON", 4) == 0 && strlen(dup) == 4) > *fac = LOG_CRON; > #endif > - else if (strncmp(dup, "LOCAL0", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL0", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL0; > - else if (strncmp(dup, "LOCAL1", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL1", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL1; > - else if (strncmp(dup, "LOCAL2", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL2", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL2; > - else if (strncmp(dup, "LOCAL3", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL3", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL3; > - else if (strncmp(dup, "LOCAL4", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL4", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL4; > - else if (strncmp(dup, "LOCAL5", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL5", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL5; > - else if (strncmp(dup, "LOCAL6", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL6", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL6; > - else if (strncmp(dup, "LOCAL7", 6) && strlen(dup) == 6) > + else if (strncmp(dup, "LOCAL7", 6) == 0 && strlen(dup) == 6) > *fac = LOG_LOCAL7; > > return 0; > > Modified: trunk/OpenDNSSEC/signer/tools/sorter.c > =================================================================== > --- trunk/OpenDNSSEC/signer/tools/sorter.c 2010-01-27 15:49:33 UTC(rev 2730) > +++ trunk/OpenDNSSEC/signer/tools/sorter.c 2010-01-28 09:43:12 UTC(rev 2731) > @@ -433,7 +433,7 @@ > default_ttl = lookup_minimum(rr_files[file_count]); > rewind(rr_files[file_count]); > soa_minimum_set = 1; > - } > + } > > line_len = read_line(rr_files[file_count], line, 1, 0); > if (line_len >= 0 && !line_contains_space_only(line, line_len)) { > > _______________________________________________ > Opendnssec-commits mailing list > Opendnssec-commits at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-commits -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Jan 28 09:47:26 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 28 Jan 2010 10:47:26 +0100 Subject: [Opendnssec-develop] Fw: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2731 - in trunk/OpenDNSSEC: . conf signer/tools In-Reply-To: References: Message-ID: <930EBF10-4601-4A9D-851C-F2D24B7300DB@kirei.se> On 28 jan 2010, at 10.46, alexd at nominet.org.uk wrote: > Is trunk open for minor fixes? I thought we were freezing all OpenDNSSEC changes until 1.0.0 release? Or else committing to a 1.0.0RC4 release? hold on, we'll decide shortly... Matthijs got a temporary free pass. jakob From Alexd at nominet.org.uk Thu Jan 28 09:57:38 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Thu, 28 Jan 2010 09:57:38 +0000 Subject: [Opendnssec-develop] Fw: [Opendnssec-commits] [keihatsu.kirei.se/svn/dnssec] r2731 - in trunk/OpenDNSSEC: . conf signer/tools In-Reply-To: <930EBF10-4601-4A9D-851C-F2D24B7300DB@kirei.se> References: <930EBF10-4601-4A9D-851C-F2D24B7300DB@kirei.se> Message-ID: > hold on, we'll decide shortly... Matthijs got a temporary free pass. Code changes are code changes, surely? Or are we no longer concerned to have no code changes between the final release candidate and the final release? I have a change I'd like to add : to drop rubygems from the list of required dependencies. Is this a code change which requires a new release for testing? Thanks, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Jan 28 11:02:24 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 28 Jan 2010 12:02:24 +0100 Subject: [Opendnssec-develop] move programs commands Message-ID: <5A64181A-7E60-47F1-95D3-5044C66FCC87@kirei.se> I think we should move the following programs from PREFIX/bin to PREFIX/sbin: - ods-control - ods-signer and maybe also: - ods-auditor? does this make sense? jakob From sion at nominet.org.uk Thu Jan 28 11:15:41 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 28 Jan 2010 11:15:41 +0000 Subject: [Opendnssec-develop] move programs commands In-Reply-To: <5A64181A-7E60-47F1-95D3-5044C66FCC87@kirei.se> References: <5A64181A-7E60-47F1-95D3-5044C66FCC87@kirei.se> Message-ID: > I think we should move the following programs from PREFIX/bin to PREFIX/sbin: > > - ods-control > - ods-signer Before the 1.0 release? Or for 1.1? > and maybe also: > > - ods-auditor? This almost belongs in the libexec directory, or is that going away when the signer is in c? Sion From jakob at kirei.se Thu Jan 28 11:32:06 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 28 Jan 2010 12:32:06 +0100 Subject: [Opendnssec-develop] move programs commands In-Reply-To: References: <5A64181A-7E60-47F1-95D3-5044C66FCC87@kirei.se> Message-ID: <57E4B0CF-A159-469D-8038-F291413BFD79@kirei.se> On 28 jan 2010, at 12.15, sion at nominet.org.uk wrote: >> I think we should move the following programs from PREFIX/bin to > PREFIX/sbin: >> >> - ods-control >> - ods-signer > > Before the 1.0 release? Or for 1.1? 1.0 >> and maybe also: >> >> - ods-auditor? > > This almost belongs in the libexec directory, or is that going away when > the signer is in c? it is a command-line tool as well, just like named-checkzone. jakob From owner-dnssec-trac at kirei.se Thu Jan 28 11:38:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 28 Jan 2010 11:38:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #88: Race condition in key backup? In-Reply-To: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> References: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> Message-ID: <054.ec25f3b58c92cc93edd0b9b94a8e1e78@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: --------------------+------------------------------------------------------- Old description: > If I read the documentation correctly, there is a race condition in the > manual key backup procedure. > > While I am doing a backup, keys may still be generated automatically by > OpenDNSSEC. This makes it difficult to decide when I should submit the > "ods-ksmutil backup done" command? > > If I submit the command before making the backup, I would initiate the > use of keys that haven't been backed up yet. But if I submit the command > after making the backup, I could have missed backing up a key that just > got created, and again, cause it to be used before it is backed up. > > I don't know if/how the key generation can be stopped during the backup > procedure. Also, using "ksmutil backup list" does not reveal the number > of keys standing by for backup so I could verify that none got added, nor > does "ksmutil backup done" tell me how many keys have been marked fit- > for-use, let alone that it would have me constrain how many it could mark > fit-for-use. > > Ideally, backups would be a 2-phase procedure, but a work-around could be > anything that ensures that no keys were generated since the backup > started. Is there a way we can document how to avoid this race condition > by following a (slightly more complicated) procedure, so DNS > administrators can be absolutely certain that all the keys in use have > been backed up if is used? New description: -- Comment(by vanrein): We talked about this problem; it would be possible to backup keys with OpenDNSSEC down, or at least the KASP Enforcer. Sion, just to be sure: Is it always OK to run "ksmutil backup done" with OpenDNSSEC down (or at least the KASP Enforcer)? -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Thu Jan 28 11:38:30 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 28 Jan 2010 12:38:30 +0100 Subject: [Opendnssec-develop] move programs commands In-Reply-To: References: <5A64181A-7E60-47F1-95D3-5044C66FCC87@kirei.se> Message-ID: <4B617736.2080100@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sion at nominet.org.uk wrote: > This almost belongs in the libexec directory, or is that going away when > the signer is in c? Yes, the binaries are going to be included in the c signer. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLYXcwAAoJEA8yVCPsQCW5cVoH/0mnB8I5B0PMcbbwrSnp6Lgi 61746sZTM8XaHaTnzcOkzmde6NzHxkNYUlGRplkiuwgRLg+nWNeO+AdPIZ6QxT3E jb0Td9w8ENqkKVFXlEotzC8N2nJvNlo5saIwalG/SvADtv1ISitFtpLyXFBP9RgH fX+N6Lig/5fGo/8yeaVnwP2cQ70/ieIjICRoIw3Bu0fjllnh1zu9HhOccwn8fn/q Qayg7mu0I9MPvZh8X4jzssTOs+Kw5r56xQuApcLDpmKSosIPIG+VIyYU8AKcnryr 26MSm/5uZj8YZWpAkZ02+WsRmtavg5YrgFlYqfxC+kN4WDqw62FXnTTysWVEErs= =VWrS -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Jan 28 11:43:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 28 Jan 2010 11:43:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #88: Race condition in key backup? In-Reply-To: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> References: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> Message-ID: <054.05bf2126153a625e583a61210a39ae84@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: --------------------+------------------------------------------------------- Comment(by sion): Yes. So long as the kasp database is not locked then it should be fine. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 28 13:26:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 28 Jan 2010 13:26:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #88: Race condition in key backup? In-Reply-To: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> References: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> Message-ID: <054.b3a52e73db0f671f3c7cff5a8873c1dc@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by vanrein): * status: new => closed * resolution: => worksforme Old description: New description: Then this closes the issue of this bug report; a 2-phase approach for backups is still commendable for later versions of OpenDNSSEC: ksmutil backup start ksmutil backup done -- Comment: Then this closes the issue of this bug report; a 2-phase approach for backups is still commendable for later versions of OpenDNSSEC: ksmutil backup start ksmutil backup done -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 28 13:30:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 28 Jan 2010 13:30:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #88: Race condition in key backup? In-Reply-To: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> References: <045.b562d1a4256c11afa664ee7e9abd6790@kirei.se> Message-ID: <054.e54d7499fdde0b304e0d340a494a321e@kirei.se> #88: Race condition in key backup? --------------------+------------------------------------------------------- Reporter: vanrein | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Comment(by jakob): this can be done today using: {{{ ods-control ksm stop ... do backup ... ods-control ksm start ods-ksmutil backup done }}} ... as the Enforcer cannot do anything while the backup is running anyway. -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Thu Jan 28 13:59:32 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 28 Jan 2010 13:59:32 +0000 Subject: [Opendnssec-develop] backup race condition Message-ID: Shall I create a story in pivotal for this? (Otherwise it may well get forgotten.) Should a "backup start" command time out after a while? Or should there be some other protection against forgetting to run "backup done"? Sion From jakob at kirei.se Thu Jan 28 14:03:44 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 28 Jan 2010 15:03:44 +0100 Subject: [Opendnssec-develop] backup race condition In-Reply-To: References: Message-ID: <35BF3D5B-CEFF-4A03-AB8B-F6621F8D3CCA@kirei.se> On 28 jan 2010, at 14.59, sion at nominet.org.uk wrote: > Shall I create a story in pivotal for this? (Otherwise it may well get > forgotten.) IMHO, we can just forget it and leave it to the sysadmin. jakob From sion at nominet.org.uk Thu Jan 28 14:09:59 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 28 Jan 2010 14:09:59 +0000 Subject: [Opendnssec-develop] backup race condition In-Reply-To: <35BF3D5B-CEFF-4A03-AB8B-F6621F8D3CCA@kirei.se> References: <35BF3D5B-CEFF-4A03-AB8B-F6621F8D3CCA@kirei.se> Message-ID: > > Shall I create a story in pivotal for this? (Otherwise it may well get > > forgotten.) > > IMHO, we can just forget it and leave it to the sysadmin. Okay. Should we add something to the documentation then, along the lines of: "Keys generated between a backup being made and the backup done command being run will be erroneously marked as having been backed up. To avoid this either choose a backup schedule that doesn't run while the enforcer might be generating keys or shutdown the enforcer while a backup is performed". Sion From jakob at kirei.se Thu Jan 28 14:13:09 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 28 Jan 2010 15:13:09 +0100 Subject: [Opendnssec-develop] backup race condition In-Reply-To: References: <35BF3D5B-CEFF-4A03-AB8B-F6621F8D3CCA@kirei.se> Message-ID: <8F458F42-D418-4A1F-80A2-0597EAF1AABE@kirei.se> On 28 jan 2010, at 15.09, sion at nominet.org.uk wrote: > Okay. Should we add something to the documentation then, along the lines > of: > > "Keys generated between a backup being made and the backup done command > being run will be erroneously marked as having been backed up. To avoid > this either choose a backup schedule that doesn't run while the enforcer > might be generating keys or shutdown the enforcer while a backup is > performed". yes, please add. j From rick at openfortress.nl Thu Jan 28 14:17:19 2010 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 28 Jan 2010 14:17:19 +0000 Subject: [Opendnssec-develop] backup race condition In-Reply-To: References: Message-ID: <20100128141719.GA638@phantom.vanrein.org> Hello Sion, > Shall I create a story in pivotal for this? (Otherwise it may well get > forgotten.) Good idea, yeah, thanks! > Should a "backup start" command time out after a while? Or should there be > some other protection against forgetting to run "backup done"? Thinking out aloud: The current "backup done" moves keys from a state "just generated" to "ready for use" -- I imagine you'd split this into two transitions with an intermediate state: "backup start" moves keys from "just generated" to "standing by for backup" and "backup done" moves keys from "standing by for backup" to "ready for use". It may not be an explicit state diagram, but it's probably comparable in function. In that situation, forgetting to backup is not an operator error that can lead to problems: keys will runout, which may lead to error messages, but that's all. What would be a problem is doing "backup done" (like we currently do) when there are no keys "standing by for backup". So what I would propose: "backup start" -> See if any keys were "standing by for backup" prior to this invocation and log a warning but continue; -> See if any keys are "just generated" and give a message and exit with a warning value to signal that nothing needs backup; -> Change any keys that were "just generated" to "standing by for backup" and exit with no error code. "backup done" -> If no keys are in state "standing by for backup" raise an error that "backup start" should be issued on >0 keys first; -> Any keys in state "standing by for backup" are moved over to "ready for use". I can't find any way of misusing that system... but let that be a challenge to others ;-) Cheers, -Rick From rick.zijlker at sidn.nl Thu Jan 28 15:09:06 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 28 Jan 2010 16:09:06 +0100 Subject: [Opendnssec-develop] hsmspeed not optimal? Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A3@KAEVS1.SIDN.local> Hey all, I'm running hsmspeed with 8 threads and lots of iterations, but it looks like it's not using the full potential of the machine. The load gets evenly divided over the 8 cores. Is this intended? This way I can't get an estimate of the performance when signing with 8 full cores. PRC | sys 0.38s | user 9.79s | #thr 149 | #zombie 1 | #exit 0 | CPU | sys 4% | user 98% | irq 0% | idle 698% | wait 0% | cpu | sys 0% | user 13% | irq 0% | idle 86% | cpu000 w 0% | cpu | sys 1% | user 13% | irq 0% | idle 86% | cpu006 w 0% | cpu | sys 1% | user 13% | irq 0% | idle 86% | cpu004 w 0% | cpu | sys 0% | user 13% | irq 0% | idle 87% | cpu007 w 0% | cpu | sys 1% | user 12% | irq 0% | idle 87% | cpu005 w 0% | cpu | sys 1% | user 12% | irq 0% | idle 87% | cpu002 w 0% | cpu | sys 0% | user 12% | irq 0% | idle 88% | cpu001 w 0% | cpu | sys 0% | user 9% | irq 0% | idle 90% | cpu003 w 0% | MEM | tot 15.7G | free 10.9G | cache 4.0G | buff 409.3M | slab 224.4M | SWP | tot 16.0G | free 16.0G | | vmcom 273.1M | vmlim 23.8G | DSK | cciss/c0d0 | busy 0% | read 0 | write 6 | avio 4 ms | NET | transport | tcpi 1 | tcpo 1 | udpi 0 | udpo 0 | NET | network | ipi 201 | ipo 1 | ipfrw 0 | deliv 201 | NET | dev eth0 | pcki 201 | pcko 1 | in 28 Kbps | out 0 Kbps | PID SYSCPU USRCPU VGROW RGROW USERNAME THR ST EXC S CPU CMD 1/1 19701 0.37s 9.78s 0K 8K root 9 -- - S 102% ods-hsmspeed 20700 0.01s 0.01s 0K 0K root 1 -- - R 0% atop Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Thu Jan 28 15:15:01 2010 From: sion at nominet.org.uk (sion at nominet.org.uk) Date: Thu, 28 Jan 2010 15:15:01 +0000 Subject: [Opendnssec-develop] backup race condition In-Reply-To: <20100128141719.GA638@phantom.vanrein.org> References: <20100128141719.GA638@phantom.vanrein.org> Message-ID: > Thinking out aloud: [snip] > I can't find any way of misusing that system... but let that be a > challenge to others ;-) We have a difference of opinion then, do we need this functionality or should it be a note in the documentation for the SA to read... Whatever happens, this functionality won't make v1.0.0; so I'll put in the documentation note for now. I'll also create this story but leave it in the icebox. That way we can think about whether we want it for v1.1, or v2.0 or if it stays in the icebox; but it won't get forgotten. Sion From rick at openfortress.nl Thu Jan 28 15:25:29 2010 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 28 Jan 2010 15:25:29 +0000 Subject: [Opendnssec-develop] hsmspeed not optimal? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A3@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86A3@KAEVS1.SIDN.local> Message-ID: <20100128152529.GD1694@phantom.vanrein.org> Rick, Inhowfar are you generating new keys? We noticed that LUNA SA slows down immensely (it is craving for entropy, basically) wheres a continuous signing operation should be able to load it fully. Slow keygen is good... it means that it takes entopy seriously. Not sure if this helps, but perhaps it does. -Rick From rick.zijlker at sidn.nl Thu Jan 28 15:33:46 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 28 Jan 2010 16:33:46 +0100 Subject: [Opendnssec-develop] hsmspeed not optimal? References: <850A39016FA57A4887C0AA3C8085F949014D86A3@KAEVS1.SIDN.local> <20100128152529.GD1694@phantom.vanrein.org> Message-ID: <850A39016FA57A4887C0AA3C8085F949014D86A4@KAEVS1.SIDN.local> Hey Rick, Actually I ran this test at SoftHSM. It just finished. Here's the log: -- [root at signer2 ~]# ods-hsmspeed -r softHSM -i 500000 -t 8 Opening HSM Library... Generating temporary key... Temporary key created: 4717225f27c412e6ce4a52700f8d0a5d Signing 500000 RRsets with RSA/SHA1 using 8 threads... Signer thread #0 started... Signer thread #2 started... Signer thread #1 started... Signer thread #4 started... Signer thread #3 started... Signer thread #5 started... Signer thread #6 started... Signer thread #7 started... Signer thread #7 done. Signer thread #5 done. Signer thread #1 done. Signer thread #3 done. Signer thread #6 done. Signer thread #0 done. Signer thread #4 done. Signer thread #2 done. Signing done. 8 threads, 500000 signatures per thread, 810.82 sig/s (RSA 1024 bits) Deleting temporary key... -- This with RC3. In RC2 I got towards 5000 sig/s with the same configuration so it feels like something is wrong. It even slows down now when running more threads: -- [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 1 Opening HSM Library... Generating temporary key... Temporary key created: 4d58758ce514f68cdd3dd2e543444927 Signing 5000 RRsets with RSA/SHA1 using 1 thread... Signer thread #0 started... Signer thread #0 done. Signing done. 1 thread, 5000 signatures per thread, 1033.65 sig/s (RSA 1024 bits) Deleting temporary key... [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 8 Opening HSM Library... Generating temporary key... Temporary key created: 8bb75d13e51565000285fe9df3c8409e Signing 5000 RRsets with RSA/SHA1 using 8 threads... Signer thread #0 started... Signer thread #1 started... Signer thread #2 started... Signer thread #3 started... Signer thread #4 started... Signer thread #5 started... Signer thread #6 started... Signer thread #7 started... Signer thread #3 done. Signer thread #6 done. Signer thread #0 done. Signer thread #7 done. Signer thread #4 done. Signer thread #1 done. Signer thread #2 done. Signer thread #5 done. Signing done. 8 threads, 5000 signatures per thread, 823.79 sig/s (RSA 1024 bits) Deleting temporary key... -- Cheers, Rick -----Original Message----- From: Rick van Rein [mailto:rick at openfortress.nl] Sent: donderdag 28 januari 2010 16:25 To: Rick Zijlker Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] hsmspeed not optimal? Rick, Inhowfar are you generating new keys? We noticed that LUNA SA slows down immensely (it is craving for entropy, basically) wheres a continuous signing operation should be able to load it fully. Slow keygen is good... it means that it takes entopy seriously. Not sure if this helps, but perhaps it does. -Rick From roy at nominet.org.uk Fri Jan 29 05:39:28 2010 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 29 Jan 2010 00:39:28 -0500 Subject: [Opendnssec-develop] hsmspeed not optimal? In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D86A4@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F949014D86A3@KAEVS1.SIDN.local> <20100128152529.GD1694@phantom.vanrein.org> <850A39016FA57A4887C0AA3C8085F949014D86A4@KAEVS1.SIDN.local> Message-ID: Rick Zijlker wrote on 01/28/2010 10:33:46 AM: > Hey Rick, > > Actually I ran this test at SoftHSM. It just finished. Here's the log: Rick, I build hsm-speed, of which ods-hsmspeed is derivative (which does the same thing as hsm-speed, but uses libhsm instead of direct pkcs11 calls). The idea is that you start with 1 thread and a certain number of iterations, say 10000. You note the speed, and you run again with a larger number of iterations. If the speed increases, you continue increasing iterations until it reaches its full potential. When more iterations doesn't increase speed, increase threads. Same deal here, continue increasing threads until you get the highest speed. Note: contrary to common believe, the amount of threads does NOT relate to the amount of cores. Hence, 8 threads might still be scheduled to two or three cores or so. The original hsm-speed contained 'forking' as well, but that has been left out of ods-hsmspeed. You can't assign threads or forked children to cores, it all depends on the kernel/cpu relation, and is thus highly platform and cpu dependent. To circumvent that, you have to use the throttling I described above. I do not know what has been changed between rc2 and rc3 at the moment (I have limited bandwidth to check, as I am on the road currently). Hope this helps a bit. Roy > > -- > [root at signer2 ~]# ods-hsmspeed -r softHSM -i 500000 -t 8 > Opening HSM Library... > Generating temporary key... > Temporary key created: 4717225f27c412e6ce4a52700f8d0a5d > Signing 500000 RRsets with RSA/SHA1 using 8 threads... > Signer thread #0 started... > Signer thread #2 started... > Signer thread #1 started... > Signer thread #4 started... > Signer thread #3 started... > Signer thread #5 started... > Signer thread #6 started... > Signer thread #7 started... > Signer thread #7 done. > Signer thread #5 done. > Signer thread #1 done. > Signer thread #3 done. > Signer thread #6 done. > Signer thread #0 done. > Signer thread #4 done. > Signer thread #2 done. > Signing done. > 8 threads, 500000 signatures per thread, 810.82 sig/s (RSA 1024 bits) > Deleting temporary key... > -- > > This with RC3. In RC2 I got towards 5000 sig/s with the same > configuration so it feels like something is wrong. > It even slows down now when running more threads: > > -- > [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 1 > Opening HSM Library... > Generating temporary key... > Temporary key created: 4d58758ce514f68cdd3dd2e543444927 > Signing 5000 RRsets with RSA/SHA1 using 1 thread... > Signer thread #0 started... > Signer thread #0 done. > Signing done. > 1 thread, 5000 signatures per thread, 1033.65 sig/s (RSA 1024 bits) > Deleting temporary key... > > [root at signer2 ~]# ods-hsmspeed -r softHSM -i 5000 -t 8 > Opening HSM Library... > Generating temporary key... > Temporary key created: 8bb75d13e51565000285fe9df3c8409e > Signing 5000 RRsets with RSA/SHA1 using 8 threads... > Signer thread #0 started... > Signer thread #1 started... > Signer thread #2 started... > Signer thread #3 started... > Signer thread #4 started... > Signer thread #5 started... > Signer thread #6 started... > Signer thread #7 started... > Signer thread #3 done. > Signer thread #6 done. > Signer thread #0 done. > Signer thread #7 done. > Signer thread #4 done. > Signer thread #1 done. > Signer thread #2 done. > Signer thread #5 done. > Signing done. > 8 threads, 5000 signatures per thread, 823.79 sig/s (RSA 1024 bits) > Deleting temporary key... > -- > > > Cheers, > Rick > > > -----Original Message----- > From: Rick van Rein [mailto:rick at openfortress.nl] > Sent: donderdag 28 januari 2010 16:25 > To: Rick Zijlker > Cc: opendnssec-develop at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] hsmspeed not optimal? > > Rick, > > Inhowfar are you generating new keys? We noticed that LUNA SA slows > down immensely (it is craving for entropy, basically) wheres a > continuous signing operation should be able to load it fully. > > Slow keygen is good... it means that it takes entopy seriously. > > Not sure if this helps, but perhaps it does. > > -Rick > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexd at nominet.org.uk Fri Jan 29 16:23:31 2010 From: Alexd at nominet.org.uk (Alexd at nominet.org.uk) Date: Fri, 29 Jan 2010 16:23:31 +0000 Subject: [Opendnssec-develop] dnsruby Message-ID: Hi - I have some fixes in dnsruby for the crazy owner names in all.rr.binary.org. If these are OK, I'll make a new dnsruby release for RC4 purposes. I'm not around on Monday, but I can do this on Tuesday morning before the RC4 release is tagged. Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: