From rickard.bellgrim at iis.se Mon Jan 3 15:03:35 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 3 Jan 2011 16:03:35 +0100 Subject: [Opendnssec-develop] Next meeting 20110105 Message-ID: <7820E266-D53C-43B5-B796-2E4CC04F3CCC@iis.se> Greetings The next meeting will be on Wednesday. Date: Wednesday 5 January Time: 14:00-15:00 CET, 13:00-14:00 GMT You can find the agenda on: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-01-05 // Rickard From Roland.vanRijswijk at surfnet.nl Mon Jan 3 15:24:00 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Mon, 3 Jan 2011 16:24:00 +0100 Subject: [Opendnssec-develop] Next meeting 20110105 In-Reply-To: <7820E266-D53C-43B5-B796-2E4CC04F3CCC@iis.se> References: <7820E266-D53C-43B5-B796-2E4CC04F3CCC@iis.se> Message-ID: Hi guys, I see that "Build Farm" is on the agenda; if any input on this from me is required, please let me know in advance since I will not be able to dial-in because I'm in another meeting at the same time. Cheers, Roland On 3 jan 2011, at 16:03, Rickard Bellgrim wrote: > Greetings > > The next meeting will be on Wednesday. > > Date: Wednesday 5 January > Time: 14:00-15:00 CET, 13:00-14:00 GMT > > You can find the agenda on: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-01-05 > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard.bellgrim at iis.se Wed Jan 5 07:53:12 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 5 Jan 2011 08:53:12 +0100 Subject: [Opendnssec-develop] Solaris Message-ID: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> Hi When I build on Solaris I get this: ../../../enforcer/enforcerd/enforcer.c: In function `NewDSSet': ../../../enforcer/enforcerd/enforcer.c:1828: warning: implicit declaration of function `popen' ../../../enforcer/enforcerd/enforcer.c:1828: warning: assignment makes pointer from integer without a cast ../../../enforcer/enforcerd/enforcer.c:1839: warning: implicit declaration of function `pclose' ../../../enforcer/utils/ksmutil.c: In function `get_lite_lock': ../../../enforcer/utils/ksmutil.c:3802: warning: implicit declaration of function `fileno' ../../../enforcer/utils/ksmutil.c: In function `printKey': ../../../enforcer/utils/ksmutil.c:5820: warning: implicit declaration of function `strcasecmp' Should we define __EXTENSIONS__? // Rickard From sion at nominet.org.uk Thu Jan 6 11:52:30 2011 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 6 Jan 2011 11:52:30 +0000 Subject: [Opendnssec-develop] OpenSolaris tests In-Reply-To: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> References: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> Message-ID: <201101061152.31840.sion@nominet.org.uk> Morning. Building and running on opensolaris I had to set my CFLAGS variable to "- std=c99" to avoid some fatal errors with stdio.h . I'm not sure if this is something new or not but I imagine it is more to do with my installation (which is a bit broken). Once this is done though it builds (with the warnings that Rickard pointed out previously). More importantly it seems to run okay... simulate_hudson runs with only one error: Zone all.rr.org was not correctly signed which I believe that we see on other systems (I certainly see it on my desktop so this is not a solaris-specific problem). I then did some other ad-hoc poking around with hsmutil and ksmutil with no issues (that I couldn't explain); so if there are any problems on solaris then they must be subtle. Sion From matthijs at NLnetLabs.nl Thu Jan 6 13:15:08 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 Jan 2011 14:15:08 +0100 Subject: [Opendnssec-develop] OpenSolaris tests In-Reply-To: <201101061152.31840.sion@nominet.org.uk> References: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> <201101061152.31840.sion@nominet.org.uk> Message-ID: <4D25C05C.7040604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/06/2011 12:52 PM, Sion Lloyd wrote: > Once this is done though it builds (with the warnings that Rickard pointed out > previously). More importantly it seems to run okay... simulate_hudson runs > with only one error: > > Zone all.rr.org was not correctly signed > > which I believe that we see on other systems (I certainly see it on my desktop > so this is not a solaris-specific problem). Yeah, if I remember correctly, that zone has occluded data that we now don't allow. I left it there, so we have a test that fails as well (as expected). Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNJcBbAAoJEA8yVCPsQCW5zS8H/jBKqnWZ6g6lm6RpeT42yWzo vP9OBk1g55wVpJLGjefM6czYHhKUw95Ju8x0WAHcP2kL5hLox0rKKhq5VPRon0St kHPPoJqeLwHCAiNbjCS4lwFoAOOJeXwS5kxKMv7oIYKlh9teSci8H/jhn7hy+GQt BpAEAIx6viOZQt1T34u+mia3KHfhePWFjZPqGaz9KZQBSq9IRyOdTACJVDX8twba sWDnWUx1dSL+J0V5ZkUlWCvPYTpRJneMfYGd9o2zpzCDfU/qGDuWBjQudhwKSSTG NYbM28UwAM694QXff/2Sm+2Vv3MtJS+08FQXIq+TtF2BbrqBwT23saRR6qgvlMA= =tiaY -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Jan 6 18:11:10 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Jan 2011 18:11:10 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip Message-ID: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- As reported at http://bugs.debian.org/609138 by David Carter Package: libhsm-bin Version: 1.1.3-3 Severity: important I had to recompile opendnssec with debugging symbols to get a backtrace but made no other changes from 1.1.3-3. This same error occurs in the official package. This system is set up to use the TPM chip as a HSM using opencryptoki 2.2.8 and 'ods-hsmutil test' completes successfully. However, when I try to use ods-hsmutil to list the keys in the HSM it segfaults (gdb backtrace follows.) I have not yet tried to use opendnssec to sign a zone as I was testing with ods-hsmutil during the initial configuration process. Backtrace: $ LD_PRELOAD=/lib/libpthread.so.0 gdb ods-hsmutil GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/ods-hsmutil...done. (gdb) run list Starting program: /usr/bin/ods-hsmutil list [Thread debugging using libthread_db enabled] Listing keys in all repositories. 1 key found. Repository ID Type ---------- -- ---- Program received signal SIGSEGV, Segmentation fault. 0x00000000004019bd in cmd_list (argc=0, argv=0x7fffffffeca8) at ../../../libhsm/src/hsmutil.c:114 114 snprintf(key_type, sizeof(key_type), (gdb) thread apply all bt full Thread 1 (Thread 0x7ffff7fee700 (LWP 25083)): #0 0x00000000004019bd in cmd_list (argc=0, argv=0x7fffffffeca8) at ../../../libhsm/src/hsmutil.c:114 key_info = 0x0 key = 0x0 key_type = "@\347`", '\000' "\260, \353\377\377\377\177\000" i = 0 repository = 0x0 key_count = 1 keys = 0x604550 ctx = 0x0 key_info_format = 0x402b3f "%-20s %-32s %-10s\n" #1 0x000000000040223e in main (argc=0, argv=0x7fffffffeca8) at ../../../libhsm/src/hsmutil.c:405 result = 0 config = 0x0 ch = -1 Here's the output from 'ods-hsmutil test ' for reference: $ ods-hsmutil test Testing repository: Generating 512-bit RSA key... OK Extracting key identifier... OK, b4d69efa6e655bc88a0897280e48b48a Signing (RSA/SHA1) with key... OK Signing (RSA/SHA256) with key... OK Deleting key... OK Generating 768-bit RSA key... Failed generate key pair: CKR_KEY_SIZE_RANGE Generating 1024-bit RSA key... OK Extracting key identifier... OK, 94efe89cad1d42e67921d1c3bc2269c4 Signing (RSA/SHA1) with key... OK Signing (RSA/SHA256) with key... OK Signing (RSA/SHA512) with key... OK Deleting key... OK Generating 1536-bit RSA key... Failed generate key pair: CKR_KEY_SIZE_RANGE Generating 2048-bit RSA key... OK Extracting key identifier... OK, 1b5551755fbec292100127ed4f156f50 Signing (RSA/SHA1) with key... OK Signing (RSA/SHA256) with key... OK Signing (RSA/SHA512) with key... OK Deleting key... OK Generating 4096-bit RSA key... Failed generate key pair: CKR_KEY_SIZE_RANGE Generating 1024 bytes of random data... OK Generating 32-bit random data... 1938355139 Generating 64-bit random data... 17955271592229176371 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 6 18:19:50 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 06 Jan 2011 18:19:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip In-Reply-To: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> References: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> Message-ID: <074.dbe5a64f9b2b34b74988a07c8f0f8a04@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- Comment(by dcarter@?): I submitted this bug to Debian with this additional information. Here is the contents of the HSM as reported by pkcs11-tool: $ pkcs11-tool --module /usr/lib/opencryptoki/libopencryptoki.so.0 --login --list-objects Please enter User PIN: Private Key Object; RSA label: KSK2011 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: KSK2011 Usage: encrypt, verify, wrap -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Jan 10 08:31:50 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 10 Jan 2011 09:31:50 +0100 Subject: [Opendnssec-develop] OpenSolaris tests In-Reply-To: <201101061152.31840.sion@nominet.org.uk> References: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> <201101061152.31840.sion@nominet.org.uk> Message-ID: On 6 jan 2011, at 12.52, Sion Lloyd wrote: > Building and running on opensolaris I had to set my CFLAGS variable to "- > std=c99" to avoid some fatal errors with stdio.h . Which part of the code gave build errors when this flag was not present? // Rickard From sion at nominet.org.uk Mon Jan 10 08:58:22 2011 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 10 Jan 2011 08:58:22 +0000 Subject: [Opendnssec-develop] OpenSolaris tests In-Reply-To: References: <76947A11-C865-42CB-B564-0D802900DF47@iis.se> <201101061152.31840.sion@nominet.org.uk> Message-ID: <201101100858.22494.sion@nominet.org.uk> On Monday 10 Jan 2011 8:31:50 am Rickard Bellgrim wrote: > On 6 jan 2011, at 12.52, Sion Lloyd wrote: > > Building and running on opensolaris I had to set my CFLAGS variable to > > "- std=c99" to avoid some fatal errors with stdio.h . > > Which part of the code gave build errors when this flag was not present? Anything that includes stdio.h or stdlib.h... In each case an "_iso" version also gets included (so stdio_iso.h or stdlib_iso.h) which redifines 'restrict' with a conflicting type. I strongly suspect that this is peculiar to my installation as no-one else has seen it. I have set up a "clean" opensolaris VM but have not had time to go through installing all the dependencies yet. Sion From rick at openfortress.nl Mon Jan 10 09:25:32 2011 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 10 Jan 2011 09:25:32 +0000 Subject: [Opendnssec-develop] DB version management tool: deltasql Message-ID: <20110110092532.GA8089@phantom.vanrein.org> Hello, We have had to change the DB scheme on occasion, and more changes are probably going to come with the new Enforcer. We're now piling up such changes to a pivotal point such as a major version change, but I ran into an alternative. Has anyone ever used the tool "deltasql"? It looks very useful for keeping versions of DB schemes up to date with the software that runs it: http://deltasql.org/ In short, it'd mean: * Entering all DB structure changing statements into deltasql * Offering such structure changes for download from a server * Installers contact the server for locally needed structure updates * Manual users can do the same through a web-interface to that server I don't know if it'll pay itself back, but I thought I'd mention it. Cheers, -Rick From rickard.bellgrim at iis.se Mon Jan 10 09:30:06 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 10 Jan 2011 10:30:06 +0100 Subject: [Opendnssec-develop] Release of v1.2.0 Message-ID: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> Hi I am starting this thread so that we can check what could hold us off from a release. * User report the we cannot us more than 10 HSM:s This is because of a define in libhsm.h. We could increase the value to e.g. 1000. This value is only used when defining the size of session array in the context. And is checked when a session is created. Other part of the code uses the session counter. This should thus not slow down any operation if we increase the HSM_MAX_SESSIONS. To follow our process we should save this change for the next release. * Signconf not reloaded and hanging threads This was in the python code. And does not involve v1.2. But we should probably have a look into this. * Build issues on a virtual OpenSolaris Sion had some issues building on OpenSolaris. He needed to add "-std=c99" to make it build. This behavior is not seen on other platforms or on the Solaris machine. We will see how the testing goes. // Rickard From rene at xpt.nl Tue Jan 11 08:08:23 2011 From: rene at xpt.nl (=?iso-8859-1?Q?Ren=E9_Post?=) Date: Tue, 11 Jan 2011 09:08:23 +0100 Subject: [Opendnssec-develop] Enforcer NG test, using protocol buffers to acccess configuration data from C++ In-Reply-To: References: Message-ID: <882CDD88-D50F-4D24-94DF-AD01BC5F0AFE@xpt.nl> For the enforcer NG I've taken a look at the database and concluded that over half of the tables is related to storing a flattened version of the kasp.xml file. I've taken two days to create a proof of concept using Google's protocol buffers that could do the same job better. Attached you'll find a PDF document describing the work done and the kasp.proto file used to generated the configuration wrappers. The idea is to discuss this in the enforcer telephone meeting this afternoon. Best regards, Ren? -------------- next part -------------- A non-text attachment was scrubbed... Name: protobuf-20110111.pdf Type: application/pdf Size: 114089 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: kasp.proto Type: application/octet-stream Size: 4117 bytes Desc: not available URL: -------------- next part -------------- From rene at xpt.nl Tue Jan 11 08:43:24 2011 From: rene at xpt.nl (=?iso-8859-1?Q?Ren=E9_Post?=) Date: Tue, 11 Jan 2011 09:43:24 +0100 Subject: [Opendnssec-develop] Enforcer N, proof of concept object relational mapper In-Reply-To: <882CDD88-D50F-4D24-94DF-AD01BC5F0AFE@xpt.nl> References: <882CDD88-D50F-4D24-94DF-AD01BC5F0AFE@xpt.nl> Message-ID: For the enforcer NG we need a way to access the database from the C++ code. I've taken two days to create a proof of concept using BSD licensed liteSQL to see what that entails. Attached you'll find a PDF document describing the work done and the kaspdb.xml file used to generated the Object Relational mapping. The idea is to discuss this in the enforcer telephone meeting this afternoon. Best regards, Ren? -------------- next part -------------- A non-text attachment was scrubbed... Name: litesql-20110111.pdf Type: application/pdf Size: 118459 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: kaspdb.xml Type: application/xml Size: 2019 bytes Desc: not available URL: -------------- next part -------------- From rene at xpt.nl Tue Jan 11 09:06:20 2011 From: rene at xpt.nl (=?iso-8859-1?Q?Ren=E9_Post?=) Date: Tue, 11 Jan 2011 10:06:20 +0100 Subject: [Opendnssec-develop] Enforcer NG test, using protocol buffers to acccess configuration data from C++ In-Reply-To: <201101110846.57553.sion@nominet.org.uk> References: <882CDD88-D50F-4D24-94DF-AD01BC5F0AFE@xpt.nl> <201101110846.57553.sion@nominet.org.uk> Message-ID: Hi Sion, Thanks for your feedback. > Something that we have discussed a number of times in the past is why we have > the database replicating the xml file... It leads to problems of knowing which > is the correct information etc. Well the XML data is still in the database, just encoded and collapsed to a single field in the policy table. This encoded configuration is leading for enforcer operation. I just got an eerie "Maslow's hammer" feeling when I noticed how it was stored, but perhaps I'm wrong. > > There is an argument for getting rid of it and just reading the xml. > > One reason for keeping the database is for a future development where we > wanted a GUI configuration tool. I guessed you'd probably want to generate and XML file and then tell the enforcer to import this policy. > (The original database was ruby on rails > compatible; I'm not sure if that is still the case.) This is the first I've heard of it, I don't know why that is important > I just thought that I'd mention this in case it is still a possibility. Nothing is set in stone yet, we are still going to discuss this later today. For this test a lot of the time was spend on getting an accurate specification of the configuration data that is actually represented in the database and how that maps to the configuration file. Best regards, Ren? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roland.vanRijswijk at surfnet.nl Tue Jan 11 12:19:19 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 11 Jan 2011 13:19:19 +0100 Subject: [Opendnssec-develop] Conference details for Enforcer TNG call Message-ID: Hi guys, Here are the conference details for the Enforcer TNG call this afternoon: Time: 15:00h - 16:00h CET Dial-in to +31-30-2040323 Conference PIN: 030003 --- Proposed agenda: 0. Agenda bashing 1. Discuss project plan proposal by Rickard 2. Discuss Ren?'s proposals for interfacing with the database and the resulting dependencies 3. Discuss the state of Yuri's work 4. AOB --- Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rene at xpt.nl Tue Jan 11 13:34:25 2011 From: rene at xpt.nl (=?iso-8859-1?Q?Ren=E9_Post?=) Date: Tue, 11 Jan 2011 14:34:25 +0100 Subject: [Opendnssec-develop] Enforcer NG, prioritized worklist In-Reply-To: References: Message-ID: <2A5A726B-D1C5-4C12-87A6-86D617081441@xpt.nl> I generated a prioritized worklist for enforcer NG that on the face of it makes sense to me. Ren? -------------- next part -------------- A non-text attachment was scrubbed... Name: worklist-enforcer-20110111.pdf Type: application/pdf Size: 85426 bytes Desc: not available URL: -------------- next part -------------- From rickard.bellgrim at iis.se Wed Jan 12 10:23:36 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 12 Jan 2011 11:23:36 +0100 Subject: [Opendnssec-develop] OpenDNSSEC processes Message-ID: Hi As I promised some time ago, I have now written down and updated some processes. You can find them here: http://trac.opendnssec.org/wiki/ProjectPlan/DevelopmentProcess http://trac.opendnssec.org/wiki/ProjectPlan/ReleaseManagement http://trac.opendnssec.org/wiki/ProjectPlan/DocumentationManagement A number of the steps in the development process needs more text, but this is a start. // Rickard From roland.vanrijswijk at surfnet.nl Wed Jan 12 10:56:27 2011 From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk) Date: Wed, 12 Jan 2011 11:56:27 +0100 Subject: [Opendnssec-develop] Meeting minutes Enforcer TNG 11-1-2011 Message-ID: <804F67BF-EDD5-4D48-906D-F373EC075371@surfnet.nl> Hi guys, I've posted meeting minutes for the Enforcer TNG telecon that was held yesterday. Please review them and make any changes you deem necessary. http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-01-11 Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard.bellgrim at iis.se Wed Jan 12 14:22:37 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 12 Jan 2011 15:22:37 +0100 Subject: [Opendnssec-develop] Release of v1.2.0 In-Reply-To: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> References: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> Message-ID: <810DCA35-718D-41AC-88ED-5130FD11C13A@iis.se> On 10 jan 2011, at 10.30, Rickard Bellgrim wrote: > * Build issues on a virtual OpenSolaris > Sion had some issues building on OpenSolaris. He needed to add "-std=c99" to make it build. This behavior is not seen on other platforms or on the Solaris machine. We will see how the testing goes. I think we could do a release. This problem has not been seen on other platform, and it builds on Solaris. // Rickard From sion at nominet.org.uk Wed Jan 12 14:50:45 2011 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 12 Jan 2011 14:50:45 +0000 Subject: [Opendnssec-develop] Release of v1.2.0 In-Reply-To: <810DCA35-718D-41AC-88ED-5130FD11C13A@iis.se> References: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> <810DCA35-718D-41AC-88ED-5130FD11C13A@iis.se> Message-ID: <201101121450.45661.sion@nominet.org.uk> On Wednesday 12 Jan 2011 2:22:37 pm Rickard Bellgrim wrote: > On 10 jan 2011, at 10.30, Rickard Bellgrim wrote: > > * Build issues on a virtual OpenSolaris > > Sion had some issues building on OpenSolaris. He needed to add "-std=c99" > > to make it build. This behavior is not seen on other platforms or on the > > Solaris machine. We will see how the testing goes. > > I think we could do a release. This problem has not been seen on other > platform, and it builds on Solaris. I certainly don't think that this issue should stop a release. Sion From rickard.bellgrim at iis.se Wed Jan 12 14:56:29 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 12 Jan 2011 15:56:29 +0100 Subject: [Opendnssec-develop] Release of v1.2.0 In-Reply-To: <201101121450.45661.sion@nominet.org.uk> References: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> <810DCA35-718D-41AC-88ED-5130FD11C13A@iis.se> <201101121450.45661.sion@nominet.org.uk> Message-ID: <32053EEA-E407-4FD6-8AB2-63BC8F84C168@iis.se> On 12 jan 2011, at 15.50, Sion Lloyd wrote: >> I think we could do a release. This problem has not been seen on other >> platform, and it builds on Solaris. > > I certainly don't think that this issue should stop a release. Jakob, you are now approved to do a release. Just remember to update the date in the NEWS file. // Rickard From owner-dnssec-trac at kirei.se Wed Jan 12 17:45:13 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 12 Jan 2011 17:45:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip In-Reply-To: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> References: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> Message-ID: <074.a5af777bc5fa2a8312c48e8a6aa512e2@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: new Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- Comment(by dcarter@?): I was able to work around this bug by deleting the key in the HSM (which had a label but not an id) and creating a new key with ods-hsmutil. I recommend that documentation be added that warns that there may not be any keys in the repository which were not created by ods-hsmutil. To delete the old keys I used pkcs11-destroy which comes with BIND 9: $ pkcs11-destroy -m /usr/lib/opencryptoki/libopencryptoki.so.0 Enter Pin: object[0]: class 3 label 'KSK2011' id[0] object[1]: class 2 label 'KSK2011' id[0] sleeping 5 seconds... $ ods-hsmutil list Listing keys in all repositories. 0 keys found. Repository ID Type ---------- -- ---- $ ods-hsmutil generate rsa 2048 Generating 2048 bit RSA key in repository: Key generation successful: d590bebdd83670a7e292d750f47da809 $ ods-hsmutil list Listing keys in all repositories. 1 key found. Repository ID Type ---------- -- ---- d590bebdd83670a7e292d750f47da809 RSA/2048 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 12 20:55:17 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 12 Jan 2011 20:55:17 -0000 Subject: [Opendnssec-develop] =?utf-8?b?W09wZW5ETlNTRUNdICMyMDU6INCh0L0=?= =?utf-8?b?0Y/RgtGMINC/0YDQvtGB0YLQuNGC0YPRgtC60YMg0LIg0JzQvtGB0LrQstC1?= Message-ID: <047.872232979763d0bb214824645c43f137@kirei.se> #205: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ----------------------+----------------------------------------------------- ????? ??????????? ? ?????? http://sexdosug.uni.cc -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Jan 12 21:02:22 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 12 Jan 2011 21:02:22 -0000 Subject: [Opendnssec-develop] =?utf-8?b?UmU6IFtPcGVuRE5TU0VDXSAjMjA1OiA=?= =?utf-8?b?0KHQvdGP0YLRjCDQv9GA0L7RgdGC0LjRgtGD0YLQutGDINCyINCc0L7RgdC6?= =?utf-8?b?0LLQtQ==?= In-Reply-To: <047.872232979763d0bb214824645c43f137@kirei.se> References: <047.872232979763d0bb214824645c43f137@kirei.se> Message-ID: <056.6c3be7a0e02f105f01c4083a1a6635ec@kirei.se> #205: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Changes (by jakob): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 13 08:29:14 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Jan 2011 08:29:14 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip In-Reply-To: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> References: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> Message-ID: <074.63e328c7c9c036624d4ad7095f473b4e@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: accepted Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- Changes (by rb): * owner: jakob => rb * status: new => accepted Comment: Yes, this was fixed in trunk r3465. Would you like to have it for the v1.1 branch? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Jan 13 08:37:47 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 13 Jan 2011 08:37:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip In-Reply-To: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> References: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> Message-ID: <074.8d6c8583b14a6cdc8a9801dc3652a596@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: accepted Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- Comment(by rb): Also r3461, r3462, r3466, r3467, and r3482. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jakob at kirei.se Thu Jan 13 19:59:37 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 13 Jan 2011 20:59:37 +0100 Subject: [Opendnssec-develop] Release of v1.2.0 In-Reply-To: <32053EEA-E407-4FD6-8AB2-63BC8F84C168@iis.se> References: <2216B7AD-B814-4ECE-A6AB-AF4F52B2BA98@iis.se> <810DCA35-718D-41AC-88ED-5130FD11C13A@iis.se> <201101121450.45661.sion@nominet.org.uk> <32053EEA-E407-4FD6-8AB2-63BC8F84C168@iis.se> Message-ID: <4BA53615-641F-49F0-9013-7FAF978042DD@kirei.se> On 12 jan 2011, at 15.56, Rickard Bellgrim wrote: > Jakob, you are now approved to do a release. Just remember to update the date in the NEWS file. release released :-) j From matthijs at NLnetLabs.nl Fri Jan 14 12:03:13 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 14 Jan 2011 13:03:13 +0100 Subject: [Opendnssec-develop] adapter design Message-ID: <4D303B81.4080106@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On the 26th, we will have another teleconf. One of the topics will be how to implement the other adapters. These are my initial thoughts: * Drop the zonefetcher, make adapters part of the zone list. It has an advantage that it becomes more flexible: you can set the acl per zone. It has the risk that the same information has to be copied many times. * When there is a Zone Transfer adapter (AXFR, IXFR), start of a thread that handles incoming notifies and transfer requests (replaces the zone fetcher). The thread has access to the zone structures, so we can easily implement soa refresh, retry and expire. A thread removes the issues with privilege dropping and process communication. * What to do with ods-signer sign when the zone as a AXFR/IXFR adapter? (Force transfer request?, read the last transferred zone?) Attached are the proposed differences to the syntax. Most changes are adapted from the zonefetch.rnc Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNMDuBAAoJEA8yVCPsQCW5vvsIAMc2V7feuVgagQX0RxnoAVDv xLOrNIlmOfAhGAsHqOvvGjHOeBO8DMGLk9r1Ike6pSk9YFPipRBroAoxMQ9btf5J PDHIlBaETnzjfdN73f2iCf+s0hFSmbfFU+dZvfV0mDK8lkuD8+mvVo4TZOQMy6bg +LDO6aTjyK7IwMa78InbqaRieZJKgLdMunjotttstBxAg0RJ06/DTI49RIhcaJiU N9sqoQ3egId3Tp9Z0V5L5hh/bb8uwvK30e2LIKuCkkHcjK8H3dpBIkwxTQUS6n3S EfuOqe067SHkRkT3+gMMKhGwcCaPS4hCsQkmnW9y9ZjVi4bzUKbk0kA5NxnPN0w= =du4S -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: zonelist.rnc.diff Type: text/x-patch Size: 1354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zonelist.rnc.diff.sig Type: application/octet-stream Size: 287 bytes Desc: not available URL: From owner-dnssec-trac at kirei.se Sat Jan 15 08:51:02 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sat, 15 Jan 2011 08:51:02 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #206: Run away zone serial ? Message-ID: <055.92187ea21936c331b17c840e99fc5d31@kirei.se> #206: Run away zone serial ? ------------------------------+--------------------------------------------- Reporter: hostmaster@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- After ods-signer sign 1.168.192.in-addr.arpa following appears in logfile: Jan 15 09:43:25 opendnssec ods-signerd: cmdhandler: zone 1.168.192.in- addr.arpa scheduled for immediate re-sign Jan 15 09:43:25 opendnssec ods-signerd: cannot update domain: serial 2930244825 should be larger than domain internal serial 0 Jan 15 09:43:25 opendnssec ods-signerd: unable to update zonedata to serial 2930244825: serial too small Jan 15 09:43:25 opendnssec ods-signerd: task [update zone 96.138.193.in- addr.arpa] failed unsigned/1.168.192.in-addr.arpa looks like: $TTL 3600 ; 1 hour @ IN SOA opendnssec.local. hostmaster.local. ( 2011011400 16384 3600 2419199 3600 ) ; @ NS ns1.local. @ NS ns2.local. ; 0 PTR 1.168.192.local. 1 PTR 1.1.168.192.local. 16 PTR centos.local. 17 PTR users.local. signed/1.168.192.in-addr.arpa has following soa: 96.138.193.in-addr.arpa. 3600 IN SOA opendnssec.local. hostmaster.local. 2011010810 16384 3600 2419199 3600 Other zones are working w/o problems. version is opendnssec-1.2.0rc3 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Jan 16 08:07:28 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 16 Jan 2011 08:07:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #206: Run away zone serial ? In-Reply-To: <055.92187ea21936c331b17c840e99fc5d31@kirei.se> References: <055.92187ea21936c331b17c840e99fc5d31@kirei.se> Message-ID: <064.daa99dd3ebcb71c0ecc0f24a969f512b@kirei.se> #206: Run away zone serial ? ------------------------------+--------------------------------------------- Reporter: hostmaster@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Comment(by hostmaster@?): '''Workaround''' Problem was caused by an invalid entry in 1.168.192.in-addr.arpa.state: {{{ ;ODSSE1 ;name: 1.168.192.in-addr.arpa ;class: 1 ;fetch: 0 ;default_ttl: 3600 ;inbound_serial: 2011011500 ;internal_serial: 2930244825 ;outbound_serial: 2011011500 ;ODSSE1 }}} I have no clue, from where that serial 2930244825 have come, but following procedures bring that zone back into game: 1. stop opendnssec 1. manually change serial to outbound_serial+1 1. start opendnssec After that, zone can be signed and everything works again. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Jan 17 08:49:16 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 Jan 2011 08:49:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #206: Run away zone serial ? In-Reply-To: <055.92187ea21936c331b17c840e99fc5d31@kirei.se> References: <055.92187ea21936c331b17c840e99fc5d31@kirei.se> Message-ID: <064.65dbc90ff61ed9019c9a0353b49cc670@kirei.se> #206: Run away zone serial ? ------------------------------+--------------------------------------------- Reporter: hostmaster@? | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Changes (by matthijs): * owner: rb => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Jan 17 10:45:24 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 17 Jan 2011 11:45:24 +0100 Subject: [Opendnssec-develop] Meeting 2011-01-26 and face-to-face in february Message-ID: Hi The next telephone meeting will be about the adapter design for the signer. Date: Wednesday 26 January Time: 14:00-15:00 CET, 13:00-14:00 GMT http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-01-26 We should also try to schedule two days where we discuss and work with OpenDNSSEC v1.3. Please mark the days that you would like to have the meeting on. You can also select the meeting location, Stockholm or Amsterdam. http://www.doodle.com/yrykam7bg3t8dpi8 // Rickard From AlexD at nominet.org.uk Tue Jan 18 09:27:52 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 18 Jan 2011 09:27:52 +0000 Subject: [Opendnssec-develop] Re: [Opendnssec-user] how does auditor calculate delays? In-Reply-To: References: <4D2EF2F2.7020601@restena.lu> Message-ID: Hi Rickard - >> Why is the SOA ttl considered for the check? DNSKEY TTL I'd understand, >> but SOA? > > Yes, that sounds strange. The first ZSK should be pre-published according to this time: > Ipub = Dprp + min(TTLsoa, SOAmin) > > The following ZSK:s should be pre-published using this time: > Ipub = Dprp + TTLkey > > We will have a look at this. >From the spec ( http://trac.opendnssec.org/wiki/Signer/AuditorRequirements ) : "Give an error if a key is seen in use without it having first been seen as prepublished for a time of at least the zone SOA TTL. [E]" Should the specification be changed? Thanks, Alex. From patrik.wallstrom at iis.se Wed Jan 19 12:50:15 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 19 Jan 2011 13:50:15 +0100 Subject: [Opendnssec-develop] SOA serial arithmetics Message-ID: <085A905E-A18F-4719-8205-56780002E547@iis.se> I am currently working with a number of zones that have serial numbers that are larger than 2147483647. See RFC1982 on the arithmetics. (I am using 1.2.0 for these tests.) What my experience so far is that the ods-signer does not believe those serials are larger than 0 when using the serial "keep" option. I believe this to be incorrect. And increments after those larger numbers are also supposed to be larger than the previous increment (but I have not checked this yet in ods), regardless of those serials being larger than 2147483647. First, am I correct in assuming this? I believe that this is how BIND handles zone transfers. Can somebody please take a look at this? -- 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 patrik.wallstrom at iis.se Wed Jan 19 13:17:50 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 19 Jan 2011 14:17:50 +0100 Subject: [Opendnssec-develop] SOA serial arithmetics In-Reply-To: <085A905E-A18F-4719-8205-56780002E547@iis.se> References: <085A905E-A18F-4719-8205-56780002E547@iis.se> Message-ID: <4B39662F-2BFA-43AB-BB66-57123C7D2CDE@iis.se> On Jan 19, 2011, at 1:50 PM, Patrik Wallstr?m wrote: > I am currently working with a number of zones that have serial numbers that are larger than 2147483647. See RFC1982 on the arithmetics. (I am using 1.2.0 for these tests.) > > What my experience so far is that the ods-signer does not believe those serials are larger than 0 when using the serial "keep" option. I believe this to be incorrect. And increments after those larger numbers are also supposed to be larger than the previous increment (but I have not checked this yet in ods), regardless of those serials being larger than 2147483647. First, am I correct in assuming this? I believe that this is how BIND handles zone transfers. > > Can somebody please take a look at this? Btw, this is the error message: Jan 19 09:08:57 mask ods-signerd: cannot update domain: serial 2460834512 should be larger than domain internal serial 0 -- 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 matthijs at NLnetLabs.nl Thu Jan 20 09:42:40 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 20 Jan 2011 10:42:40 +0100 Subject: [Opendnssec-develop] SOA serial arithmetics In-Reply-To: <085A905E-A18F-4719-8205-56780002E547@iis.se> References: <085A905E-A18F-4719-8205-56780002E547@iis.se> Message-ID: <4D380390.5020203@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Patrik, This probably happens the first time the signer has to deal with the zone. The first time a zone is loaded in OpenDNSSEC, it will internally get the serial 0. According to RFC 1982, section 3.1: Serial numbers may be incremented by the addition of a positive integer n, where n is taken from the range of integers [0 .. (2^(SERIAL_BITS - 1) - 1)]. ... Addition of a value outside the range is undefined. To conclude, the behavior of adding a value larger than 2147483647 ((2^31)-1) is undefined. OpenDNSSEC checks accordingly RFC 1982 if the inbound serial is larger than its internal serial. That's why the error message appears. How to resolve? 1. First present the zone to OpenDNSSEC with a serial <= (2^31)-1. Update the serial to the value you want > (2^31)-1 and run ods-signer sign 2. I could make code that initializes a domain. If not initialized, no serial number is known and any serial number is allowed. However, I am not sure if this will raise less or more issues. Best regards, Matthijs On 01/19/2011 01:50 PM, Patrik Wallstr?m wrote: > I am currently working with a number of zones that have serial numbers that are larger than 2147483647. See RFC1982 on the arithmetics. (I am using 1.2.0 for these tests.) > > What my experience so far is that the ods-signer does not believe those serials are larger than 0 when using the serial "keep" option. I believe this to be incorrect. And increments after those larger numbers are also supposed to be larger than the previous increment (but I have not checked this yet in ods), regardless of those serials being larger than 2147483647. First, am I correct in assuming this? I believe that this is how BIND handles zone transfers. > > Can somebody please take a look at this? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNOAOPAAoJEA8yVCPsQCW5XfsIAINjrxxTbXnhAmsCA6ilvz04 Rsfcn5LAaOZ9puMYVjt1qJbbxqHI+/xFFXBs3L1crYAu8zRSxXqaCwRYciHdC8Fw DFLesIi9YPodwxG35FYpSZY47RG1wcZX1qwvFgTu0PHIiP7vlRRLtJI8qnFTxffo zGCK1ChBklBZ5Qub4GbMKUGCeZ8Vm7TnqYWm82mhrh0LchvUMcFbsOAQzLV+OX7M QH5KJlTlxiCgELrOYv3h3HsOIpcyb0OWv2G9lrAE7SQCVds92vz4vFYGCdl4eq6O bhN8YDVDMR2V3Xx+vmbyl9PsX2T8vBlLOYnyJnLoYvZ1SDbRgx+7t+BAKe6UHX0= =6eo8 -----END PGP SIGNATURE----- From patrik.wallstrom at iis.se Thu Jan 20 09:50:15 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Thu, 20 Jan 2011 10:50:15 +0100 Subject: [Opendnssec-develop] SOA serial arithmetics In-Reply-To: <4D380390.5020203@nlnetlabs.nl> References: <085A905E-A18F-4719-8205-56780002E547@iis.se> <4D380390.5020203@nlnetlabs.nl> Message-ID: <87BD5736-A49C-46BB-9391-1BF143DC2E43@iis.se> On Jan 20, 2011, at 10:42 AM, Matthijs Mekking wrote: > Hi Patrik, > > This probably happens the first time the signer has to deal with the > zone. The first time a zone is loaded in OpenDNSSEC, it will internally > get the serial 0. > > According to RFC 1982, section 3.1: > > Serial numbers may be incremented by the addition of a positive > integer n, where n is taken from the range of integers [0 .. > (2^(SERIAL_BITS - 1) - 1)]. ... > > Addition of a value outside the range is undefined. > > To conclude, the behavior of adding a value larger than 2147483647 > ((2^31)-1) is undefined. > > OpenDNSSEC checks accordingly RFC 1982 if the inbound serial is larger > than its internal serial. That's why the error message appears. > > How to resolve? > 1. First present the zone to OpenDNSSEC with a serial <= (2^31)-1. > Update the serial to the value you want > (2^31)-1 and run > ods-signer sign > > 2. I could make code that initializes a domain. If not initialized, no > serial number is known and any serial number is allowed. However, I > am not sure if this will raise less or more issues. As I believe that BIND already accepts initializing with incrementing serials with serial being > 2^31-1 I think we should also consider doing a change. Maybe it will be as simple as changing the initial internal serial 0 with 2^32-1. Yes, the behavior is unidentified, and I asked the zone editors to change the serial standard they use in order to avoid this kind of problems when changing other systems in the zone distribution path. -- 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 AlexD at nominet.org.uk Tue Jan 25 09:06:34 2011 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 25 Jan 2011 09:06:34 +0000 Subject: Fwd: [Opendnssec-develop] Re: [Opendnssec-user] how does auditor calculate delays? References: Message-ID: <083D9C2C-0033-42BC-BF50-B01A690F8B51@nominet.org.uk> Anyone? Begin forwarded message: From: Alex Dalitz > Date: 18 January 2011 09:27:52 GMT To: Rickard Bellgrim > Cc: "opendnssec-develop at lists.opendnssec.org" > Subject: [Opendnssec-develop] Re: [Opendnssec-user] how does auditor calculate delays? Hi Rickard - Why is the SOA ttl considered for the check? DNSKEY TTL I'd understand, but SOA? Yes, that sounds strange. The first ZSK should be pre-published according to this time: Ipub = Dprp + min(TTLsoa, SOAmin) The following ZSK:s should be pre-published using this time: Ipub = Dprp + TTLkey We will have a look at this. >From the spec ( http://trac.opendnssec.org/wiki/Signer/AuditorRequirements ) : "Give an error if a key is seen in use without it having first been seen as prepublished for a time of at least the zone SOA TTL. [E]" Should the specification be changed? Thanks, Alex._______________________________________________ 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 owner-dnssec-trac at kirei.se Tue Jan 25 13:40:26 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Jan 2011 13:40:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #204: ods-hsmutil segfaults when listing keys in TPM chip In-Reply-To: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> References: <065.7a1ec9e0075516ab993f1948256b7065@kirei.se> Message-ID: <074.49554b173a51d067a717af398e7ef3c5@kirei.se> #204: ods-hsmutil segfaults when listing keys in TPM chip ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: accepted Priority: major | Component: libhsm Version: 1.1.3 | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): > Would you like to have it for the v1.1 branch? Probably not neccessary for Debian package. It's not severe enough, it cannot be triggered by user and there is a known workaround. If any of this is not true, then yes I would like to have it for v1.1 and I'll prepare security update. Else I'm fine with fix included only in v1.2 branch. O. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 25 13:48:00 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Jan 2011 13:48:00 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #207: quicksorter fails on new line comments Message-ID: <065.6a932b924c9309dc4cec4ba5ff75ef54@kirei.se> #207: quicksorter fails on new line comments ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ------------------------------------------+--------------------------------- {{{ sury.org. 7200 IN TXT "v=spf1 include:aspmx.googlemail.com ~all" ; comment _jabber._tcp.sury.org. 7200 IN SRV 5 0 5269 xmpp-server.l.google.com. }}} Causes quicksorter to print: {{{ # /usr/lib/opendnssec/opendnssec/quicksorter -o sury.org. -f sury.org. -w /dev/null sury.org.:14: Unknown RR: }}} First reported in Debian by Michael Gold: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598049 Reproduced in opendnssec 1.2.0 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 25 13:53:29 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Jan 2011 13:53:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #207: quicksorter fails on new line comments In-Reply-To: <065.6a932b924c9309dc4cec4ba5ff75ef54@kirei.se> References: <065.6a932b924c9309dc4cec4ba5ff75ef54@kirei.se> Message-ID: <074.7aedbc52d1d56c5aee519b11840e685d@kirei.se> #207: quicksorter fails on new line comments ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: ------------------------------------------+--------------------------------- Comment(by Ond?ej Sur? ): Sorry, my mistake, I have reproduced it in 1.1.3, since the quicksorter doesn't exists anymore. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 25 14:14:28 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Jan 2011 14:14:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #207: quicksorter fails on new line comments In-Reply-To: <065.6a932b924c9309dc4cec4ba5ff75ef54@kirei.se> References: <065.6a932b924c9309dc4cec4ba5ff75ef54@kirei.se> Message-ID: <074.a9a1e7eab93b792196389a7dae2bfed0@kirei.se> #207: quicksorter fails on new line comments ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: Hi Ond?ej, Fixed it in the 1.1 branch. Thanks for the report. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Jan 25 14:40:06 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Jan 2011 14:40:06 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #208: Auditor fails if domain name configured with trailing dot Message-ID: <065.b214dd5c7a3c09056dfbd271488e6099@kirei.se> #208: Auditor fails if domain name configured with trailing dot ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------------+--------------------------------- As reported at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598051 ods-auditor fails for domains listed with a trailing "." in zonelist.xml, e.g.: The error shown is: Sep 25 16:32:10 iria ods-auditor[8685]: SOA name (rilmarder.org) is different to the configured zone name (rilmarder.org.) - aborting (The SOA line refers to the domain as "@".) ods-auditor should accept the SOA line (or, zonelist.xml should contain a comment saying not to include a trailing dot, and "ods-ksmutil zone add" should prevent the user from including one). This may be related to upstream ticket #139: http://trac.opendnssec.org/ticket/139 - Michael Still true with v1.2.0: {{{ Jan 25 15:37:26 pagan ods-auditor[5441]: Auditor started Jan 25 15:37:27 pagan ods-auditor[5441]: Auditor starting on rilmarder.org. Jan 25 15:37:27 pagan ods-auditor[5441]: SOA name (rilmarder.org) is different to the configured zone name (rilmarder.org.) - aborting }}} I am listing it as separate bug since the #139 is specific for root zone. -- Ticket URL: OpenDNSSEC OpenDNSSEC From nick.vandenheuvel at sidn.nl Tue Jan 25 14:10:48 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Tue, 25 Jan 2011 14:10:48 +0000 Subject: [Opendnssec-develop] Test plan ODS 1.2 Message-ID: Hi guys, A little late maybe, but I hereby sent you my Test plan for testing ODS 1.2 from SIDN side. We hope to gain some speed at SIDN, so we can test the next releases earlier. Kind regards, Nick van den Heuvel Nick van den Heuvel Testanalist SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | F +31 (0)26 352 55 05 nick.vandenheuvel at sidn.nl | www.sidn.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenDNSSEC_1 2_english_v0 3.ppt Type: application/vnd.ms-powerpoint Size: 3488768 bytes Desc: OpenDNSSEC_1 2_english_v0 3.ppt URL: From rickard.bellgrim at iis.se Wed Jan 26 10:05:38 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 26 Jan 2011 11:05:38 +0100 Subject: [Opendnssec-develop] Test plan ODS 1.2 In-Reply-To: References: Message-ID: <5401C131-9F7C-4112-9983-A67D228BCC20@iis.se> On 25 jan 2011, at 15.10, Nick van den Heuvel wrote: > A little late maybe, but I hereby sent you my Test plan for testing ODS 1.2 from SIDN side. We hope to gain some speed at SIDN, so we can test the next releases earlier. > Nice work! // Rickard From rickard.bellgrim at iis.se Wed Jan 26 10:14:00 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 26 Jan 2011 11:14:00 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-user] how does auditor calculate delays? In-Reply-To: References: <4D2EF2F2.7020601@restena.lu> Message-ID: On 18 jan 2011, at 10.27, Alex Dalitz wrote: > Hi Rickard - > >>> Why is the SOA ttl considered for the check? DNSKEY TTL I'd understand, >>> but SOA? >> >> Yes, that sounds strange. The first ZSK should be pre-published according to this time: >> Ipub = Dprp + min(TTLsoa, SOAmin) >> >> The following ZSK:s should be pre-published using this time: >> Ipub = Dprp + TTLkey >> >> We will have a look at this. > > From the spec ( http://trac.opendnssec.org/wiki/Signer/AuditorRequirements ) : > > "Give an error if a key is seen in use without it having first been seen as prepublished for a time of at least the zone SOA TTL. [E]" > > Should the specification be changed? Yes, since that statement is not correct. We can talk more about this on today's conference call. // Rickard From matthijs at NLnetLabs.nl Wed Jan 26 11:06:59 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 26 Jan 2011 12:06:59 +0100 Subject: [Opendnssec-develop] signer 2.0 design Message-ID: <4D400053.2040808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is my attempt to visualize the design of the signer engine. Best regards, Matthijs - ----------------------------------------------------------------- Input files (orange): - - config xmlfile - - zonelist xmlfile - - one ore more signconf xmlfiles Signer client (light green): The client is the way to control the signer. The client is connected to the daemon via a unix socket. With a list of dedicated commands, the daemon can be started, stopped, reloaded and you can monitor and manage the zone list, zones and task queue. Signer daemon (also light green): The daemon is the core of the signer. up to six different type of threads are dedicated to do the work of the signer. Threads (white): - - The main thread is the engine. Starting the engine makes the signer read and store the configuration settings and zone list. In addition, it sets up a task schedule. Tasks are scheduled by time and each zone can have only one task in the schedule. - - The workers will grab tasks from the schedule and do the piece of work. The task is a subtaks, such as reading or writing a zone, adding NSEC(3) records, or RRSIG records. A worker picks the correct signconf and zone files and starts working on the task. If the appointed task is completed, the worker determines the successor task and when it needs to be executed. It puts the successor task on the schedule and grabs a new task. Note that workers do not add the RRSIG records: they delegate this hard job to the drudgers. The worker selects the RRsets that need signatures and puts them in a FIFO queue. - - Drudgers are also workers, only they have to do the hard, menial work. The drudgers will pick up the job from the FIFO queue and provide RRsets with the necessary signatures. It uses the HSM for that (through libhsm). This makes it possible to have a *threaded signer*. - - The command handler (cmdhndlr) is the so to say the help desk. It handles the commands received from the client. Some commands require action to be taken. For example, if a zone needs to be added, the command handler informs the engine. The engine adjusts the zone list and task schedule, so that the workers will follow the correct schedule. - - The fetcher will perform zone transfers. Transfers will be requested when the refresh timer for a zone expires, or when a notify is received. Such a notify can come from the command handler or from the listener. - - The listener will listen to incoming DNS packets. These can be notifies from the master or transfer requests from a secondary. Notifies are forwarded to the fetcher, transfer requests are handled by transferring the latest signed zone. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQABSAAoJEA8yVCPsQCW5GUkIAIgf73QKZuKrclvxsDr4gJ4a KzXsvgqh0uf1lwnThW2nrje6rm2/81h2P1hROPCilYc/7qXArdMFI49vDIzOpUwy GLtuWG1WZHC9gnV2EGo2LyxJarDZgUi1rlG0rcalQ3kMIAUuU434RzMP7bfYI6NX prnOekGP6RQ7Wdp4O8RxAzcD+7BU5eseqaH1t36I9aPn9ikN8DzQhZaIPY9iuAiQ SMhZXWNWOP65VlZSIOR+cqDaQ9bXFybSEX+dQkNLem4+SSQHQziY/1WYZ0cy2eP6 31FUkBrWYLMYHL7xDHOsdXupMU4/xJjhC8F23pS7S/ExWLuswZPlo2sNtHag/Qc= =ONJ5 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: ods-signer-design.pdf Type: application/pdf Size: 29720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ods-signer-design.pdf.sig Type: application/octet-stream Size: 287 bytes Desc: not available URL: From owner-dnssec-trac at kirei.se Fri Jan 28 00:30:45 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Jan 2011 00:30:45 -0000 Subject: [Opendnssec-develop] =?utf-8?b?UmU6IFtPcGVuRE5TU0VDXSAjMTU5OiA=?= =?utf-8?b?0KHQvdGP0YLRjCDQv9GA0L7RgdGC0LjRgtGD0YLQutGDINCyINCc0L7RgdC6?= =?utf-8?b?0LLQtQ==?= In-Reply-To: <047.ae256a906fce183ce9a3916adebbd970@kirei.se> References: <047.ae256a906fce183ce9a3916adebbd970@kirei.se> Message-ID: <056.4db2a640fa9a2d3570b2ccc6406b0bcd@kirei.se> #159: ????? ??????????? ? ?????? ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: alex Type: defect | Status: closed Priority: blocker | Component: Auditor Version: | Resolution: invalid Keywords: | ----------------------+----------------------------------------------------- Comment(by anonymous): ???????????????????????? http://zenol.land.ru/skachat-patch-aktivacii-dlya-guitar-pro.html http://zenol.land.ru/skachat-dynamic-auto-painter.html http://zenol.land.ru/kluch-skachat-kis-900463.html http://zenol.land.ru/skachat-besplatnye-igry-bez-registracii-dlya- komputera.html http://zenol.land.ru/skachat-msdict-for-symbian-8.html http://zenol.land.ru/skachat-programmu-sostavleniya-interera.html http://zenol.land.ru/skachat-keygen-k-nero-94molodye.html http://zenol.land.ru/skachat-tanchiki-dlya-dvoih.html http://zenol.land.ru/folder-lock-6-russkaya-versiya-skachat.html http://zenol.land.ru/skachat-virtualnyy-didzhey.html -- Ticket URL: OpenDNSSEC OpenDNSSEC From bert.hubert at netherlabs.nl Thu Jan 27 14:57:09 2011 From: bert.hubert at netherlabs.nl (bert hubert) Date: Thu, 27 Jan 2011 15:57:09 +0100 Subject: [Opendnssec-develop] [bert.hubert@netherlabs.nl: [Botan-devel] Solved! Botan Patch inside Re: potential problem with 'GOST 3410-2001' parameters, or with my code] Message-ID: <20110127145709.GD3855@xs.powerdns.com> Dear OpenDNSSEC developers, In trying to get PowerDNSSEC to validate the GOST samples from RFC 5933, I discovered problems. On browsing the Botan website I found that OpenDNSSEC added the GOST code to Botan. After a day and a night of debugging, I found a small error in the GOST code in Botan that caused the problem. Perhaps the message below will save you a day and night of debugging too ) And thanks for the code! Good luck! ----- Forwarded message from bert hubert ----- Date: Thu, 27 Jan 2011 15:49:42 +0100 From: bert hubert To: botan-devel at randombit.net Subject: [Botan-devel] Solved! Botan Patch inside Re: potential problem with 'GOST 3410-2001' parameters, or with my code Quoting RFC 4490: "The signature algorithm GOST R 34.10-2001 generates a digital signature in the form of two 256-bit numbers, r and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r". Note 's and then r', and observe the code below. OpenSSL also does 's and then r'. With this patch included, the samples from RFC 5933 validate correctly. --- src/pubkey/gost_3410/gost_3410.cpp c5f656397e7037f2ad8d4dd14da5c764ffd6ccb7 +++ src/pubkey/gost_3410/gost_3410.cpp dea8eaebdb5d0f8d4c954f02805bd5c8cf76d3d8 @@ -130,8 +130,8 @@ GOST_3410_Signature_Operation::sign(cons throw Invalid_State("GOST 34.10: r == 0 || s == 0"); SecureVector output(2*order.bytes()); + s.binary_encode(&output[output.size() - s.bytes()]); r.binary_encode(&output[output.size() / 2 - r.bytes()]); - s.binary_encode(&output[output.size() - s.bytes()]); return output; } @@ -150,8 +150,8 @@ bool GOST_3410_Verification_Operation::v BigInt e = decode_le(msg, msg_len); + BigInt s(sig + sig_len / 2, sig_len / 2); BigInt r(sig, sig_len / 2); - BigInt s(sig + sig_len / 2, sig_len / 2); if(r < 0 || r >= order || s < 0 || s >= order) return false; On Thu, Jan 27, 2011 at 11:38:15AM +0100, bert hubert wrote: > Hi everybody, > > First, let me thank you for writing & working on the wonderful Botan > library! It is a joy to work with. Even the source code mostly is a joy to > read, which is rare in the world of crypto ;-) > > Ok, now on to my problem. I'm working on implementing a compliant GOST > 3410-2001 signature & verification engine for PowerDNS > (http://www.powerdnssec.org) DNSSEC. > > This is described in RFC 5933 (DNS) and RFC 4357 (more GOST details). > > Sadly, the signatures I make with Botan verify fine, but the ones from the > internets don't. It appears I'm not compatible with the world. The GOST hash > has been verified to be correct. > > The code can be seen on: > http://wiki.powerdns.com/trac/browser/trunk/pdns/pdns/botan19signers.cc > Tarball: http://powerdnssec.org/downloads/pdns-3.0-pre.20110127.1915.tar.gz > To test, ./configure --enable-botan1.9, compile and run: ./pdnssec verify-crypto nlnetlabs > where file nlnetlabs contains: > > nlnetlabs.nl. 3600 IN DNSKEY 256 3 12 9SZY+xB3wKtrLoRHzkBs9L3fjcvazjnk5HF3gMaD1PVp4pthrwgHIm0TUaLrd3YCa2VCl5wj+MzbhZi8NEJ/Cg== > open.nlnetlabs.nl. 600 IN A 213.154.224.1 > open.nlnetlabs.nl. 600 IN RRSIG A 12 3 600 20090903100515 20090806100515 60385 nlnetlabs.nl. XVxDmt7/gRk13Yv+U+RPuEZ86iCGSVPmTcpMZYJs14Yn6Y/On8X+vgLV6IzxQTxAwGb+D35/dUfT55p6pFo8YQ== > > verify-crypto will output that the signature does not validate. There may of > course be problems unrelated to the crypto, but the same code for RSA works. > > 5933 specifies that the id-GostR3410-2001-CryptoPro-A-ParamSet > (1.2.643.2.2.35.1) parameters should be used, and this oid is indeed present > in Botan, and is called 'Gost_256A'. > > However, if I 'dumpasn1' the contents of Gost_256A from > src/libstate/policy.cpp, I get a BER sequence that looks quite a lot like > that in RFC 4357, not not quite enough to ease my doubts. > > RFC 4357 says: > 163 30 159: SEQUENCE { > 166 06 7: OBJECT IDENTIFIER > : id-GostR3410-2001-CryptoPro-A-ParamSet > 175 30 147: SEQUENCE { > 178 02 33: INTEGER > : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD > : 94 > 213 02 2: INTEGER 166 > 217 02 33: INTEGER > : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD > : 97 > 252 02 33: INTEGER > : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8 > : 93 > 287 02 1: INTEGER 1 > 290 02 33: INTEGER > : 00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B > : 76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E > : 14 > : } > : } > > And Botan contains: > 0 224: SEQUENCE { > 3 1: INTEGER 1 > 6 44: SEQUENCE { > 8 7: OBJECT IDENTIFIER prime-field (1 2 840 10045 1 1) > 17 33: INTEGER > : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD > : 97 > : } > 52 68: SEQUENCE { > 54 32: OCTET STRING > : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD 94 > 88 32: OCTET STRING > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A6 > : } > 122 65: OCTET STRING > : 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 01 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B > : 76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E > : 14 > 189 33: INTEGER > : 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > : FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8 > : 93 > 224 1: INTEGER 1 > : } > > There is a lot of similarity though, but I wonder if people have used Botan > to generate interoperale signatures before? > > Thanks! _______________________________________________ botan-devel mailing list botan-devel at randombit.net http://lists.randombit.net/mailman/listinfo/botan-devel ----- End forwarded message ----- From rickard.bellgrim at iis.se Mon Jan 31 14:21:01 2011 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 31 Jan 2011 15:21:01 +0100 Subject: [Opendnssec-develop] Meeting 2011-01-26 and face-to-face in february In-Reply-To: References: Message-ID: <4C3C5ABE-F82C-4673-BD71-43989AFE9C84@iis.se> FYI, It was decided to have the meeting in Stockholm (.SE), 9-10 feb. On 17 jan 2011, at 11.45, Rickard Bellgrim wrote: > We should also try to schedule two days where we discuss and work with OpenDNSSEC v1.3. Please mark the days that you would like to have the meeting on. You can also select the meeting location, Stockholm or Amsterdam. > > http://www.doodle.com/yrykam7bg3t8dpi8