Re: opendnssec and softhsm revisited

2015-10-13 Thread Patrik Lundin
On Mon, Oct 12, 2015 at 11:34:46PM +0100, Stuart Henderson wrote:
> On 2015/10/05 22:22, Patrik Lundin wrote:
> > The 1.4.8.2 version of opendnssec was just released. This version
> > incorporates the above mentioned fixes. You will find the port attached.
> 
> Looks good to me. I've reserved uid/gid 757 so PLIST can be updated.
> 

Great, thanks :).

>
> Only one thing I'm unsure about, I'd welcome other comments on this
> though: the naming of the mariadb flavour. It is technically correct,
> but we're not using -mariadb as a flavour name anywhere else, so I'd
> be inclined to name it "mysql" for consistency with the rest of the
> tree.
>

This sounds reasonable to me. Moving the ports tree from using "mysql"
to "mariadb" in flavor names seems like something that should be done in
a more controlled fashion than having some ports slowly start diverging.

Attached is a port with the uid/gid number updated to 757 in PLIST, as
well as having the "mariadb" name reverted to "mysql" (except in the
README file where I still refer to the mariadb-server package).

-- 
Patrik Lundin


opendnssec.tgz
Description: application/tar-gz


Re: opendnssec and softhsm revisited

2015-10-13 Thread Jérémie Courrèges-Anglas

Hi,

Patrik Lundin  writes:

> On Mon, Oct 12, 2015 at 11:34:46PM +0100, Stuart Henderson wrote:
>> On 2015/10/05 22:22, Patrik Lundin wrote:
>> > The 1.4.8.2 version of opendnssec was just released. This version
>> > incorporates the above mentioned fixes. You will find the port attached.
>> 
>> Looks good to me. I've reserved uid/gid 757 so PLIST can be updated.
>> 
>
> Great, thanks :).
>
>>
>> Only one thing I'm unsure about, I'd welcome other comments on this
>> though: the naming of the mariadb flavour. It is technically correct,
>> but we're not using -mariadb as a flavour name anywhere else, so I'd
>> be inclined to name it "mysql" for consistency with the rest of the
>> tree.
>>
>
> This sounds reasonable to me. Moving the ports tree from using "mysql"
> to "mariadb" in flavor names seems like something that should be done in
> a more controlled fashion than having some ports slowly start diverging.

+1

> Attached is a port with the uid/gid number updated to 757 in PLIST, as
> well as having the "mariadb" name reverted to "mysql" (except in the
> README file where I still refer to the mariadb-server package).

Here's an updated tarball that incorporates the following changes:
- merge two WANTLIB lines
- zap a redundant rc_reload=NO line
- tighten pexp
- use default rc_check()



opendnssec.tgz
Description: Binary data

diff -pruN opendnssec.orig/Makefile opendnssec/Makefile
--- opendnssec.orig/MakefileTue Oct 13 09:30:50 2015
+++ opendnssec/Makefile Tue Oct 13 12:42:05 2015
@@ -15,7 +15,7 @@ MAINTAINER=   Patrik Lundin 
 # BSD
 PERMIT_PACKAGE_CDROM=  Yes
 
-WANTLIB += c crypto iconv ldns m pthread xml2 z
+WANTLIB += c crypto iconv ldns lzma m pthread xml2 z
 
 MASTER_SITES=  http://dist.opendnssec.org/source/
 
@@ -33,8 +33,6 @@ CONFIGURE_ARGS+= --disable-pedantic
 
 FLAVORS=   sqlite3 mysql
 FLAVOR?=   sqlite3
-
-WANTLIB+=  lzma
 
 .if ${FLAVOR:Msqlite3}
 WANTLIB+=  sqlite3
diff -pruN opendnssec.orig/pkg/opendnssec.rc opendnssec/pkg/opendnssec.rc
--- opendnssec.orig/pkg/opendnssec.rc   Sun Apr 27 15:42:57 2014
+++ opendnssec/pkg/opendnssec.rcTue Oct 13 13:47:41 2015
@@ -8,20 +8,14 @@ daemon="${TRUEPREFIX}/sbin/ods-control"
 
 rc_reload=NO
 
-pexp="ods-"
+pexp="${TRUEPREFIX}/sbin/ods-(enforcerd|signerd)"
 
-rc_reload=NO
-
 rc_start() {
${rcexec} "${daemon} start"
 }
 
 rc_stop() {
${daemon} stop
-}
-
-rc_check() {
-   pkill -0 "^${pexp}"
 }
 
 rc_cmd $1


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


Re: opendnssec and softhsm revisited

2015-10-12 Thread Stuart Henderson
On 2015/10/05 22:22, Patrik Lundin wrote:
> The 1.4.8.2 version of opendnssec was just released. This version
> incorporates the above mentioned fixes. You will find the port attached.

Looks good to me. I've reserved uid/gid 757 so PLIST can be updated.

Only one thing I'm unsure about, I'd welcome other comments on this
though: the naming of the mariadb flavour. It is technically correct,
but we're not using -mariadb as a flavour name anywhere else, so I'd
be inclined to name it "mysql" for consistency with the rest of the
tree.



Re: opendnssec and softhsm revisited

2015-10-05 Thread Patrik Lundin
On Sat, Sep 19, 2015 at 11:24:12AM +0200, Patrik Lundin wrote:
> 
> Just a quick update: both the segfault on i386 and the lockup on macppc
> has been fixed on the development branch.
> 
> I'll send an updated port as soon as the fixes are available in a
> release which may be out in the upcoming week.
> 

The 1.4.8.2 version of opendnssec was just released. This version
incorporates the above mentioned fixes. You will find the port attached.

The only issue I have seen was on sparc64 where some kind of self-check
in the botan library would fail once:

/var/log/messages:
===
Sep 26 08:25:01 ns3-old ods-enforcerd: opendnssec started (version 1.4.8), pid 
28386
Sep 26 08:25:03 ns3-old ods-signerd: [hsm] libhsm connection opened succesfully
Sep 26 08:25:03 ns3-old ods-signerd: [engine] signer started (version 1.4.8), 
pid 17887
Sep 26 08:26:00 ns3-old ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair 
generated
Sep 26 08:26:00 ns3-old ods-enforcerd: SoftHSM: C_DestroyObject: An object has 
been destroyed
Sep 26 08:26:00 ns3-old ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair 
generated
Sep 26 08:26:00 ns3-old ods-enforcerd: SoftHSM: C_DestroyObject: An object has 
been destroyed
Sep 26 08:26:00 ns3-old ods-enforcerd: WARNING: Making non-backed up ZSK 
active, PLEASE make sure that you know the potential problems of using keys 
which are not recoverable
Sep 26 08:26:00 ns3-old ods-signerd: [signconf] zone example.com signconf: 
RESIGN[PT7200S] REFRESH[PT259200S] VALIDITY[PT1209600S] DENIAL[PT1209600S] 
JITTER[PT43200S] OFFSET[PT3600S] NSEC[50] DNSKEYTTL[PT3600S] SOATTL[PT3600S] 
MINIMUM[PT3600S] SERIAL[unixtime]
Sep 26 08:26:00 ns3-old ods-signerd: SoftHSM: C_Sign: Could not sign the data: 
Internal error: Assertion self_test_signature(encoded, plain_sig) failed 
(PK_Signer consistency check failed) in Botan::SecureVector 
Botan::PK_Signer::signature(Botan::RandomNumberGenerator&) 
@./src/pubkey/pubkey.cpp:219
Sep 26 08:26:00 ns3-old ods-signerd: [hsm] sign final: CKR_GENERAL_ERROR
Sep 26 08:26:00 ns3-old ods-signerd: [hsm] error signing rrset with libhsm
Sep 26 08:26:00 ns3-old ods-signerd: [rrset] unable to sign RRset[50]: 
lhsm_sign() failed
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] sign zone example.com failed: 
1 RRsets failed
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] CRITICAL: failed to sign zone 
example.com: General error
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] backoff task [sign] for zone 
example.com with 60 seconds
Sep 26 08:27:00 ns3-old ods-signerd: [STATS] example.com 1443248820 RR[count=5 
time=0(sec)] NSEC3[count=3 time=0(sec)] RRSIG[new=2 reused=7 time=0(sec) 
avg=0(sig/sec)] TOTAL[time=60(sec)] 
===

/var/log/daemon:
===
Sep 26 08:26:00 ns3-old ods-signerd: [cmdhandler] received command update 
example.com[18]
Sep 26 08:26:00 ns3-old ods-signerd: [zonelist] read file 
/etc/opendnssec/zonelist.xml
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] configure zone example.com
Sep 26 08:26:00 ns3-old ods-enforcerd: Called signer engine: 
/usr/local/sbin/ods-signer update example.com
Sep 26 08:26:00 ns3-old ods-enforcerd: Disconnecting from Database...
Sep 26 08:26:00 ns3-old ods-enforcerd: Sleeping for 3600 seconds.
Sep 26 08:26:00 ns3-old ods-signerd: [signconf] zone example.com signconf: 
RESIGN[PT7200S] REFRESH[PT259200S] VALIDITY[PT1209600S] DENIAL[PT1209600S] 
JITTER[PT43200S] OFFSET[PT3600S] NSEC[50] DNSKEYTTL[PT3600S] SOATTL[PT3600S] 
MINIMUM[PT3600S] SERIAL[unixtime]
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] read zone example.com
Sep 26 08:26:00 ns3-old ods-signerd: [adapter] read zone example.com from file 
input adapter /var/opendnssec/unsigned/example.com
Sep 26 08:26:00 ns3-old ods-signerd: [adapter] zone example.com set soa ttl to 
3600
Sep 26 08:26:00 ns3-old ods-signerd: [adapter] zone example.com set soa minimum 
to 3600
Sep 26 08:26:00 ns3-old ods-signerd: [adapter] zone example.com set soa serial 
to 1443248760
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] sign zone example.com
Sep 26 08:26:00 ns3-old ods-signerd: [hsm] sign final: CKR_GENERAL_ERROR
Sep 26 08:26:00 ns3-old ods-signerd: [hsm] error signing rrset with libhsm
Sep 26 08:26:00 ns3-old ods-signerd: [rrset] unable to sign RRset[50]: 
lhsm_sign() failed
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] sign zone example.com failed: 
1 RRsets failed
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] CRITICAL: failed to sign zone 
example.com: General error
Sep 26 08:26:00 ns3-old ods-signerd: [worker[2]] backoff task [sign] for zone 
example.com with 60 seconds
Sep 26 08:27:00 ns3-old ods-signerd: [worker[2]] sign zone example.com
Sep 26 08:27:00 ns3-old ods-signerd: [zone] zone example.com set soa serial to 
1443248820
Sep 26 08:27:00 ns3-old ods-signerd: [worker[2]] write zone example.com
Sep 26 08:27:00 ns3-old ods-signerd: [adapter] write zone example.com serial 
1443248820 to output file adapter /var/opendnssec/signed/example.com
Sep 26 08:27:00 ns3-old ods-signerd: [STATS] 

Re: opendnssec and softhsm revisited

2015-09-19 Thread Patrik Lundin
On Sun, Aug 30, 2015 at 11:32:24PM +0200, Jérémie Courrèges-Anglas wrote:
> 
> Very nice!  Yes, asking upstream is the right thing to do.
> 
> If they don't plan to do a release with that stack size problem
> addressed, I think it would be ok to import opendnssec with a temporary
> patch.
> 

Just a quick update: both the segfault on i386 and the lockup on macppc
has been fixed on the development branch.

I'll send an updated port as soon as the fixes are available in a
release which may be out in the upcoming week.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-08-30 Thread Jérémie Courrèges-Anglas
Patrik Lundin pat...@sigterm.se writes:

 On Wed, Jun 24, 2015 at 07:10:33AM +0200, Patrik Lundin wrote:
 
 The summary for now looks like this:
 Working: amd64, sparc64
 Broken: i386, macppc
 
 Is there some relation between threading and 32/64 bit? It is the main
 thing that sticks out currently, since sparc64 rules out an endian issue
 as far as i can tell.
 

Hi Patrik.  Sorry if I kinda ignored this opendnssec problem, I couldn't
find a solution quickly enough.


 So there might be some light at the end of the opendnssec tunnel.
 I have noticed that the thread stack size is smaller on i386 than it is
 on amd64 using this code snippet:
 ---
 #include stdio.h
 #include pthread.h

 pthread_attr_t attr;
 size_t stacksize;

 int main (){
 pthread_attr_init(attr);
 pthread_attr_getstacksize(attr, stacksize); 

 printf(stacksize: %d\n, stacksize);

 return 0;
 }
 ---

 While amd64 and sparc64 reports 524288, i386 says 262144. It looks like I have
 been able to stop opendnssec from crashing by modifying a wrapper function to
 pass an attribute variable to pthread_create(), increasing the stack size:
 ---
 pthread_attr_t attr;
 size_t stacksize;
 pthread_attr_init(attr);
 pthread_attr_getstacksize(attr, stacksize);
 pthread_attr_setstacksize(attr, stacksize * 2);
 ---

 The above was inspired from this thread:
 http://openbsd-archive.7691.n7.nabble.com/Default-Posix-thread-stack-size-td47465.html

 Anyway, I have sent a message regarding this to one of the nlnet people. I 
 will
 report back with how things goes. I am not sure if this is the correct fix, or
 if one should instead store less data on the stack or something.

Very nice!  Yes, asking upstream is the right thing to do.

If they don't plan to do a release with that stack size problem
addressed, I think it would be ok to import opendnssec with a temporary
patch.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: opendnssec and softhsm revisited

2015-08-30 Thread Patrik Lundin
On Wed, Jun 24, 2015 at 07:10:33AM +0200, Patrik Lundin wrote:
 
 The summary for now looks like this:
 Working: amd64, sparc64
 Broken: i386, macppc
 
 Is there some relation between threading and 32/64 bit? It is the main
 thing that sticks out currently, since sparc64 rules out an endian issue
 as far as i can tell.
 

So there might be some light at the end of the opendnssec tunnel.
I have noticed that the thread stack size is smaller on i386 than it is
on amd64 using this code snippet:
---
#include stdio.h
#include pthread.h

pthread_attr_t attr;
size_t stacksize;

int main (){
pthread_attr_init(attr);
pthread_attr_getstacksize(attr, stacksize); 

printf(stacksize: %d\n, stacksize);

return 0;
}
---

While amd64 and sparc64 reports 524288, i386 says 262144. It looks like I have
been able to stop opendnssec from crashing by modifying a wrapper function to
pass an attribute variable to pthread_create(), increasing the stack size:
---
pthread_attr_t attr;
size_t stacksize;
pthread_attr_init(attr);
pthread_attr_getstacksize(attr, stacksize);
pthread_attr_setstacksize(attr, stacksize * 2);
---

The above was inspired from this thread:
http://openbsd-archive.7691.n7.nabble.com/Default-Posix-thread-stack-size-td47465.html

Anyway, I have sent a message regarding this to one of the nlnet people. I will
report back with how things goes. I am not sure if this is the correct fix, or
if one should instead store less data on the stack or something.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-23 Thread Patrik Lundin
On Mon, Jun 22, 2015 at 05:25:52PM +0200, Patrik Lundin wrote:
 
 I did not see the problem on amd64 or sparc64 at least. I am currently
 building stuff on a fresh macppc snapshot to see what happens there.
 After that I am out of platforms :).
 

So this is interesting. It turns out ods has problems on my macppc as
well. While it does not segfault like it does on i386, the ods-signerd
process instead seems to be spinning forever after the same notify command that
makes it segfault on i386:

---
PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
380 _opendns  510   11M 7152K run   thrslee   4:25 97.12% ods-signerd
---

At the same time i see this in /var/log/daemon that i do not recognize
from before:
---
Jun 24 07:01:46 ns4-old ods-signerd: [adapter] error parsing RR at line 14 
(Syntax error, could not parse the RR): \M^?\M^?\M^?\M^?\M^?\M^?\M^?[...]
---

This is the exact same example.com zone file that is available in git:
---
# sha1 example.com  
   
SHA1 (example.com) = 60c5f533184b8cbbbe78ec4c9d455ac3effbd5bf
---

Jérémie: Let me know if you want access to the macppc machine to cross
reference the problems, just send over a public key and I'll set you up.

The summary for now looks like this:
Working: amd64, sparc64
Broken: i386, macppc

Is there some relation between threading and 32/64 bit? It is the main
thing that sticks out currently, since sparc64 rules out an endian issue
as far as i can tell.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-23 Thread Jérémie Courrèges-Anglas
Stuart Henderson st...@openbsd.org writes:

 On 2015/06/22 13:24, Jérémie Courrèges-Anglas wrote:
 Stuart Henderson st...@openbsd.org writes:
 
 
 [...]
 
  2. The i386 problems are a bit concerning, it seems quite unlikely that
  they will only affect i386.
 
 I'll take a look at them this evening, had to update my i386 box.
 
  softhsm is probably easier to test so let's look at that first. I'm
  fairly busy at the moment but I'll put it on my list to look at...
 
 Here's a diff against Patrick's tarball, and a new tarball attached.
 - don't hardcode the botan libs but use botan-config
 - no need for libsofthsm.{a,la}, ltdl is not used
 
 I think it's ready to import.

 Since it's a PKCS#11 module which can be used by various programs
 other than opendnssec, let's treat it as one - could you add the rest
 of scaffolding (diff below) so that p11-kit can find it, please?

 I considered installing the .so to lib/pkcs11, but since we can just
 use a relative link in the module file, it's easy enough to use softhsm
 upstream's preferred path, so let's do that...

 OK sthen@ with this (or probably something else similar if you have a
 different idea) added.

Nice idea.  I've just imported softhsm with your p11-kit addition.

Thanks,
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: opendnssec and softhsm revisited

2015-06-22 Thread Patrik Lundin
On Mon, Jun 22, 2015 at 09:22:41AM +0100, Stuart Henderson wrote:
 
 2. The i386 problems are a bit concerning, it seems quite unlikely that
 they will only affect i386.
 

I did not see the problem on amd64 or sparc64 at least. I am currently
building stuff on a fresh macppc snapshot to see what happens there.
After that I am out of platforms :).


 softhsm is probably easier to test so let's look at that first. I'm
 fairly busy at the moment but I'll put it on my list to look at...
 

Sounds good to me, thanks!

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-22 Thread Patrik Lundin
On Mon, Jun 22, 2015 at 01:24:35PM +0200, Jérémie Courrèges-Anglas wrote:
 Stuart Henderson st...@openbsd.org writes:
 
  2. The i386 problems are a bit concerning, it seems quite unlikely that
  they will only affect i386.
 
 I'll take a look at them this evening, had to update my i386 box.
 

Awesome! Just in case you missed my previous info: you can use
https://github.com/eest/obsd-ports/blob/master/testing/opendnssec/reset-ods.sh
to take care of the initial setup and get instructions on how I cause the crash.

There is also an example.com zone file there, so you can be sure you are
testing with the same setup I have.

  softhsm is probably easier to test so let's look at that first. I'm
  fairly busy at the moment but I'll put it on my list to look at...
 
 Here's a diff against Patrick's tarball, and a new tarball attached.
 - don't hardcode the botan libs but use botan-config
 - no need for libsofthsm.{a,la}, ltdl is not used
 
 I think it's ready to import.
 

Thanks for the feedback!

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-22 Thread Jérémie Courrèges-Anglas
Patrik Lundin pat...@sigterm.se writes:

 On Mon, Jun 22, 2015 at 01:24:35PM +0200, Jérémie Courrèges-Anglas wrote:
 Stuart Henderson st...@openbsd.org writes:
 
  2. The i386 problems are a bit concerning, it seems quite unlikely that
  they will only affect i386.
 
 I'll take a look at them this evening, had to update my i386 box.
 

 Awesome! Just in case you missed my previous info: you can use
 https://github.com/eest/obsd-ports/blob/master/testing/opendnssec/reset-ods.sh
 to take care of the initial setup and get instructions on how I cause the 
 crash.

 There is also an example.com zone file there, so you can be sure you are
 testing with the same setup I have.

That's what I used, and I can easily reproduce the problem.  Sadly the
core file doesn't help me much in finding the cause of the segfault, and
when running under gdb ods-signerd just spins endlessly.  Sucks...

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: opendnssec and softhsm revisited

2015-06-22 Thread Patrik Lundin
On Mon, Jun 22, 2015 at 11:11:05PM +0200, Jérémie Courrèges-Anglas wrote:
 
 That's what I used, and I can easily reproduce the problem.  Sadly the
 core file doesn't help me much in finding the cause of the segfault, and
 when running under gdb ods-signerd just spins endlessly.  Sucks...
 

Yeah it seems to be quite a funky problem to debug. The last guy from
NLnet labs that looked at it seemed to believe it had something to do
with threading, but was not able to make more sense of it than that.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-22 Thread Stuart Henderson
On 2015/06/22 13:24, Jérémie Courrèges-Anglas wrote:
 Stuart Henderson st...@openbsd.org writes:
 
 
 [...]
 
  2. The i386 problems are a bit concerning, it seems quite unlikely that
  they will only affect i386.
 
 I'll take a look at them this evening, had to update my i386 box.
 
  softhsm is probably easier to test so let's look at that first. I'm
  fairly busy at the moment but I'll put it on my list to look at...
 
 Here's a diff against Patrick's tarball, and a new tarball attached.
 - don't hardcode the botan libs but use botan-config
 - no need for libsofthsm.{a,la}, ltdl is not used
 
 I think it's ready to import.

Since it's a PKCS#11 module which can be used by various programs
other than opendnssec, let's treat it as one - could you add the rest
of scaffolding (diff below) so that p11-kit can find it, please?

I considered installing the .so to lib/pkcs11, but since we can just
use a relative link in the module file, it's easy enough to use softhsm
upstream's preferred path, so let's do that...

OK sthen@ with this (or probably something else similar if you have a
different idea) added.

Sample p11-kit output further below.

diff --git Makefile Makefile
index ee9c335..10cc809 100644
--- Makefile
+++ Makefile
@@ -31,5 +31,7 @@ CONFIGURE_STYLE= gnu
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/softhsm
cd ${WRKSRC}; ${INSTALL_DATA} LICENSE ${PREFIX}/share/doc/softhsm
rm ${PREFIX}/lib/softhsm/libsofthsm.*a
+   ${INSTALL_DATA} ${FILESDIR}/softhsm.module \
+   ${PREFIX}/share/examples/softhsm
 
 .include bsd.port.mk
diff --git files/softhsm.module files/softhsm.module
new file mode 100644
index 000..04905c4
--- /dev/null
+++ files/softhsm.module
@@ -0,0 +1,3 @@
+# $OpenBSD$
+
+module: ../softhsm/libsofthsm.so
diff --git pkg/PLIST pkg/PLIST
index 24c4e24..4c82b91 100644
--- pkg/PLIST
+++ pkg/PLIST
@@ -11,5 +11,9 @@ share/doc/softhsm/LICENSE
 share/examples/softhsm/
 share/examples/softhsm/softhsm.conf
 @sample ${SYSCONFDIR}/softhsm.conf
+share/examples/softhsm/softhsm.module
+@sample ${SYSCONFDIR}/pkcs11/
+@sample ${SYSCONFDIR}/pkcs11/modules/
+@sample ${SYSCONFDIR}/pkcs11/modules/softhsm.module
 @sample ${LOCALSTATEDIR}/db/softhsm/
 @comment share/examples/softhsm/softhsm.conf.sample



$ p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
library-description: PKCS#11 Kit Trust Module
library-manufacturer: PKCS#11 Kit
library-version: 0.22
token: System Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.22
flags:
   write-protected
   token-initialized
gnome-keyring: gnome-keyring-pkcs11.so
library-description: GNOME Keyring (without daemon)
library-manufacturer: GNOME Keyring
library-version: 1.1
softhsm: ../softhsm/libsofthsm.so
library-description: Implementation of PKCS11
library-manufacturer: SoftHSM
library-version: 1.3
token: OpenDNSSEC
manufacturer: SoftHSM
model: SoftHSM
serial-number: 1
hardware-version: 1.3
firmware-version: 1.3
flags:
   rng
   login-required
   user-pin-initialized
   clock-on-token
   token-initialized

$ p11tool --list-tokens
Token 0:
URL: 
pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Label: System Trust
Type: Trust module
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1


Token 1:
URL: pkcs11:model=SoftHSM;manufacturer=SoftHSM;serial=1;token=OpenDNSSEC
Label: OpenDNSSEC
Type: Generic token
Manufacturer: SoftHSM
Model: SoftHSM
Serial: 1




Re: opendnssec and softhsm revisited

2015-06-22 Thread Jérémie Courrèges-Anglas
Stuart Henderson st...@openbsd.org writes:


[...]

 2. The i386 problems are a bit concerning, it seems quite unlikely that
 they will only affect i386.

I'll take a look at them this evening, had to update my i386 box.

 softhsm is probably easier to test so let's look at that first. I'm
 fairly busy at the moment but I'll put it on my list to look at...

Here's a diff against Patrick's tarball, and a new tarball attached.
- don't hardcode the botan libs but use botan-config
- no need for libsofthsm.{a,la}, ltdl is not used

I think it's ready to import.

diff -pruN softhsm.orig/Makefile softhsm/Makefile
--- softhsm.orig/Makefile   Mon Jun 22 12:38:53 2015
+++ softhsm/MakefileMon Jun 22 13:13:45 2015
@@ -25,9 +25,11 @@ FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples/so
 
 SEPARATE_BUILD=Yes
 CONFIGURE_STYLE= gnu
+CONFIGURE_ARGS=--with-botan=${LOCALBASE}
 
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/softhsm
cd ${WRKSRC}; ${INSTALL_DATA} LICENSE ${PREFIX}/share/doc/softhsm
+   rm ${PREFIX}/lib/softhsm/libsofthsm.*a
 
 .include bsd.port.mk
diff -pruN softhsm.orig/patches/patch-configure softhsm/patches/patch-configure
--- softhsm.orig/patches/patch-configureMon Jun 22 12:38:53 2015
+++ softhsm/patches/patch-configure Mon Jun 22 13:16:51 2015
@@ -1,12 +1,14 @@
 $OpenBSD$
 configure.orig Sat Apr 26 21:59:55 2014
-+++ configure  Sat Apr 26 22:00:31 2014
-@@ -4352,7 +4352,7 @@ fi
+--- configure.orig Wed May 28 08:03:56 2014
 configure  Mon Jun 22 13:16:45 2015
+@@ -4351,8 +4351,8 @@ else
+ fi
  
  
-   BOTAN_INCLUDES=-I$BOTAN_PATH/include/botan-1.10
+-  BOTAN_INCLUDES=-I$BOTAN_PATH/include/botan-1.10
 -  BOTAN_LIBS=-L$BOTAN_PATH/lib -lbotan-1.10
-+  BOTAN_LIBS=-L$BOTAN_PATH/lib -lbotan-1.10 -lbz2 -lcrypto -lgmp 
-lpthread -lz
++  BOTAN_INCLUDES=`botan-config-1.10 --cflags`
++  BOTAN_LIBS=`botan-config-1.10 --libs`
tmp_CPPFLAGS=$CPPFLAGS
tmp_LIBS=$LIBS
CPPFLAGS=$CPPFLAGS $BOTAN_INCLUDES
diff -pruN softhsm.orig/pkg/PLIST softhsm/pkg/PLIST
--- softhsm.orig/pkg/PLIST  Mon Jun 22 12:38:53 2015
+++ softhsm/pkg/PLIST   Mon Jun 22 12:55:46 2015
@@ -2,8 +2,6 @@
 @bin bin/softhsm
 @bin bin/softhsm-keyconv
 lib/softhsm/
-lib/softhsm/libsofthsm.a
-lib/softhsm/libsofthsm.la
 lib/softhsm/libsofthsm.so
 @man man/man1/softhsm-keyconv.1
 @man man/man1/softhsm.1



softhsm.tgz
Description: Binary data

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE


Re: opendnssec and softhsm revisited

2015-06-22 Thread Stuart Henderson
On 2015/06/21 05:58, Patrik Lundin wrote:
 On Wed, Jun 17, 2015 at 08:57:35AM +0200, Patrik Lundin wrote:
  On Thu, May 21, 2015 at 08:23:49PM +0200, Patrik Lundin wrote:
   On Sat, May 16, 2015 at 06:24:11PM +0200, Patrik Lundin wrote:

You will find the latest ports attached. Except for marking opendnssec
broken on i386 I have also updated the version from 1.4.6 to 1.4.7, and
I have converted databases/mysql dependencies to databases/mariadb.

   
   Since there seems to be no further feedback from porters: If the reason
   no one is picking up these ports is a lack of spare time (which has been
   indicated earlier) I would be happy to manage them in-tree myself given
   the opportunity.
   
  
  Ping.
  
 
 I am not sure why no one feels like importing my work. I have put quite a
 lot of effort into the port, involving both ports@ and upstream to make
 the best out of the situation. I am also prepared to handle any issues
 reported by users.
 
 Anyway, I'll stop asking after this.
 
 -- 
 Patrik Lundin
 

1. It requires some ports developer to have DNSSEC setup to actually
test it prior to import (and then get review from a second developer since
policy is to have another OK to actually import things).

2. The i386 problems are a bit concerning, it seems quite unlikely that
they will only affect i386.

softhsm is probably easier to test so let's look at that first. I'm
fairly busy at the moment but I'll put it on my list to look at...



Re: opendnssec and softhsm revisited

2015-06-20 Thread Patrik Lundin
On Wed, Jun 17, 2015 at 08:57:35AM +0200, Patrik Lundin wrote:
 On Thu, May 21, 2015 at 08:23:49PM +0200, Patrik Lundin wrote:
  On Sat, May 16, 2015 at 06:24:11PM +0200, Patrik Lundin wrote:
   
   You will find the latest ports attached. Except for marking opendnssec
   broken on i386 I have also updated the version from 1.4.6 to 1.4.7, and
   I have converted databases/mysql dependencies to databases/mariadb.
   
  
  Since there seems to be no further feedback from porters: If the reason
  no one is picking up these ports is a lack of spare time (which has been
  indicated earlier) I would be happy to manage them in-tree myself given
  the opportunity.
  
 
 Ping.
 

I am not sure why no one feels like importing my work. I have put quite a
lot of effort into the port, involving both ports@ and upstream to make
the best out of the situation. I am also prepared to handle any issues
reported by users.

Anyway, I'll stop asking after this.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-06-17 Thread Patrik Lundin
On Thu, May 21, 2015 at 08:23:49PM +0200, Patrik Lundin wrote:
 On Sat, May 16, 2015 at 06:24:11PM +0200, Patrik Lundin wrote:
  
  You will find the latest ports attached. Except for marking opendnssec
  broken on i386 I have also updated the version from 1.4.6 to 1.4.7, and
  I have converted databases/mysql dependencies to databases/mariadb.
  
 
 Since there seems to be no further feedback from porters: If the reason
 no one is picking up these ports is a lack of spare time (which has been
 indicated earlier) I would be happy to manage them in-tree myself given
 the opportunity.
 

Ping.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-05-21 Thread Patrik Lundin
On Sat, May 16, 2015 at 06:24:11PM +0200, Patrik Lundin wrote:
 
 You will find the latest ports attached. Except for marking opendnssec
 broken on i386 I have also updated the version from 1.4.6 to 1.4.7, and
 I have converted databases/mysql dependencies to databases/mariadb.
 

Since there seems to be no further feedback from porters: If the reason
no one is picking up these ports is a lack of spare time (which has been
indicated earlier) I would be happy to manage them in-tree myself given
the opportunity.

-- 
Patrik Lundin



Re: opendnssec and softhsm revisited

2015-05-16 Thread Patrik Lundin
Hello again!


 I have now been updating the ports for both opendnssec and softhsm to
 the latest versions (opendnssec 1.4.6 and softhsm 1.3.7). While doing
 this I extended my testing from amd64/sparc64 to i386. Sadly this
 revealed a segfault in ods-signerd (which was present in 1.4.5 as well).


Since I posted the above message I have had people from NLnet Labs looking at
the crashes without being able to figure out what is causing them.

If anyone from the OpenBSD camp would be interested in further
debugging, I have saved helper scripts I wrote for the NLnet Labs folks,
which can be found here:
https://github.com/eest/obsd-ports/tree/master/testing/opendnssec

For this crowd reset-ods.sh would probably be the script that is most
helpful.

I have decided to just mark i386 as BROKEN in the port for now, like I
have stated earlier, I have not seen these problems on amd64 or sparc64.

You will find the latest ports attached. Except for marking opendnssec
broken on i386 I have also updated the version from 1.4.6 to 1.4.7, and
I have converted databases/mysql dependencies to databases/mariadb.

-- 
Patrik Lundin


opendnssec.tgz
Description: application/tar-gz


softhsm.tgz
Description: application/tar-gz


Re: opendnssec and softhsm revisited

2014-08-21 Thread Patrik Lundin
On Mon, Jun 02, 2014 at 09:48:41AM +0200, Patrik Lundin wrote:
 
 Is no one interested in this? I think it is a nice complement to nsd in
 base for automated DNSSEC.
 

I have now been updating the ports for both opendnssec and softhsm to
the latest versions (opendnssec 1.4.6 and softhsm 1.3.7). While doing
this I extended my testing from amd64/sparc64 to i386. Sadly this
revealed a segfault in ods-signerd (which was present in 1.4.5 as well).

I have posted a detailed report to opendnssec-user which can be read
here: http://permalink.gmane.org/gmane.network.dns.opendnssec.user/2735

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-06-02 Thread Patrik Lundin
On Tue, May 27, 2014 at 10:27:52PM +0200, Patrik Lundin wrote:
 
 The ports are now at a state where i feel they are suitable for import.
 

Is no one interested in this? I think it is a nice complement to nsd in
base for automated DNSSEC.

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-27 Thread Patrik Lundin
Hello,

The ports are now at a state where i feel they are suitable for import.

Some remaining questions:

* Do people agree daemon is the correct syslog facility to use? The 
  upstream manual recommends the use of the localX ones. (Noted on this
  page: https://wiki.opendnssec.org/display/DOCS/conf.xml). The system
  logs pretty verbosely.

* When running make port-lib-depends-check on the mysql
  FLAVOR, the following is printed:
  Asking ports for dependency mysql-client-5.1.73v0(databases/mysql,-main)

  I only react because this is the only dependency that does that, I
  guess that is OK? 

* I still have not been able to figure out what sthen@ meant by
  @owner/@group need updating in the inital review. I have used
  uid/gid 505 up until now.

* I have made sure the example simple-dnskey-mailer.sh script is
  available under /usr/local/share/opendnssec. The git repo keeps this
  file non-executable. Should I make it executable via PLIST our keep
  that as an exercise for the user if they want to use it?

* I am not convinced the pexp used in the rc-script (ods-), is
  considered safe enough, but there are two different processes that are
  started: ods-enforcerd and ods-signerd. 

* During the time that has passed working on the port, at some point I
  noticed a change in the build output: the titles of man-pages
  would appear, and then at a later date they did not. At first I was 
  worried I had introduced some bug in the Makefile, but now I am pretty
  sure http://marc.info/?l=openbsd-cvsm=139842797830466w=2 is the 
  reason (because of updated snapshots).

There are quite a few patches in the opendnssec port right now, the good
news is that except for patch-conf_conf_xml_in (syslog facility,
user/group used etc.) the other changes have been merged upstream.

The ports have recieved testing on amd64 and sparc64.

If they are found to be good enough for import I want to make sure Stuart,
Jérémie and Jerry Lundström jerry () opendnssec.org are credited for
the help so far.

Regards,
Patrik Lundin


opendnssec.tgz
Description: application/tar-gz


softhsm.tgz
Description: application/tar-gz


Re: opendnssec and softhsm revisited

2014-05-20 Thread Patrik Lundin
On Mon, May 19, 2014 at 11:55:33PM +0200, Jérémie Courrèges-Anglas wrote:
 
 It is not about this particular occurrence.  If you replace it by
 a strlcpy call, you will probably see the same warning, coming from
 another strcpy call elsewhere.
 
 Propose upstream strl* and snprintf as alternatives to the unchecked
 functions.  If upstream sees interest in this, then a careful audit of
 the code can follow, and strl* functions make error checking easier.
 Adding fallback code for OSes not providing those functions is easy too.
 

Upon mentioning these findings I was informed of the situation where an
ongoing rewrite of the code for 2.0 will make sure strcpy/strcat is not
used, so this will fix itself in time.

It is available here:
http://lists.opendnssec.org/pipermail/opendnssec-user/2014-May/002941.html

 
  The call in signer/src/wire/notify.c:
  random()%(extra-base);
 
  I guess #ifdef'ing this with HAVE_ARC4RANDOM like is done in ksm_policy.c
  would be nice.
 
 See arc4random_uniform(3), the configure seems to test for its presence.
 

The current random-related fixes on the upstream openbsd branch actually
tests for both now. Thanks for the pointer!

 
  Finally some unused variables, might as well be complete while I am at
  it:
 
  ===
  daemon/cmdhandler.c:398: warning: unused variable 'task'
 
  shared/duration.c:442: warning: 'is_leap_year' defined but not used
  shared/duration.c:449: warning: 'leap_days' defined but not used
 
  shared/hsm.c:224: warning: unused variable 'retries'
  shared/hsm.c:220: warning: unused variable 'status'
  ===
 
 Those could be harmless, or they could show a bug in the program logic.
 If you want to audit them fine, but in the end it's rather upstream's
 responsibility.
 

These was mostly intended to be seen by upstream, and some of them has
been fixed on the branch.

 We try to avoid having too much patches in the ports tree.  The best way
 is probably to work with upstream and get your patches integrated, after
 proper reviewing.  Some mistakes have been done while wrongly replacing
 eg. strcpy by strlcpy.
 

I intend to ignore the strcat/strcpy stuff for now given the above
status. The other stuff has been fixed.

Thanks a lot for your input :).

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-19 Thread Patrik Lundin
On Sun, May 18, 2014 at 07:24:00PM +0200, Patrik Lundin wrote:
 
 First up is this one:
 ===
 pin.c: In function 'hsm_shm_open':
 pin.c:209: warning: comparison between signed and unsigned
 ===
 
 Next we have this one:
 ===
 hsmspeed.c:38:1: warning: PTHREAD_THREADS_MAX redefined
 In file included from hsmspeed.c:33:
 /usr/include/pthread.h:55:1: warning: this is the location of the
 previous definition
 ===
 
 Third and final (for now):
 ===
 hsmspeed.c: In function 'sign':
 hsmspeed.c:120: warning: control reaches end of non-void function
 ===
 

Jerry Lundström from the OpenDNSSEC-team has been kind enough to create
a branch where he fixed the stuff I posted above, and made it into a pull
request:
https://github.com/opendnssec/opendnssec/pull/83

I have imported the changes as patches and those warnings are now gone.

Since they have been sorted out I'll now go through the the rest of the
warnings. Since upstream is watching I will be as verbose as possible.

First of all there are a bunch of libraries spitting out warnings on several
locations, I consider these outside the scope:

===
.libs/libxml2.so.15.1: warning: strcpy() is almost always misused, please use 
strlcpy()
.libs/libxml2.so.15.1: warning: rand_r() isn't random; consider using 
arc4random()
.libs/libldns.so.6.1: warning: random() isn't random; consider using 
arc4random()
.libs/libxml2.so.15.1: warning: strcat() is almost always misused, please use 
strlcat()
===

Now for the first warning in the code at hand:

../ksm/libksm.a(datetime.o)(.text+0x562): In function `DtSecondsInterval':
: warning: strcpy() is almost always misused, please use strlcpy()

The code looks like this:
enforcer/ksm/datetime.c:
charbuffer[64];
[...]
else {
strcpy(buffer, 0s);
}

I am not sure trying to turn this into strlcpy is worth it since the
string is static and the buffer obviously large enough. (Though I
welcome cluebats from anyone more well versed in C here).

Next up some random warnings:

===
../ksm/libksm.a(ksm_policy.o)(.text+0xd31): In function `KsmPolicyUpdateSalt':
: warning: rand() isn't random; consider using arc4random()
../ksm/libksm.a(ksm_policy.o)(.text+0xd13): In function `KsmPolicyUpdateSalt':
: warning: srand() seed choices are invariably poor
===

Now these warnings were interesting, looking into the code it looks like
this:

enforcer/ksm/ksm_policy.c:
===
#ifdef HAVE_ARC4RANDOM
for (i = 0; i  2*(policy-denial-saltlength); i++) {
salt[i] = hex_chars[arc4random()%strlen(hex_chars)];
}
#else
srand( time(NULL) );
for (i = 0; i  2*(policy-denial-saltlength); i++) {
salt[i] = hex_chars[rand()%strlen(hex_chars)];
}
#endif
===

It is obviously prepared to use arc4random() if it is available, yet it does
not for some reason.

I found HAVE_ARC4RANDOM is indeed set:
common/config.h:
===
/* Define to 1 if you have the `arc4random' function. */
#define HAVE_ARC4RANDOM 1

/* Define to 1 if you have the `arc4random_uniform' function. */
#define HAVE_ARC4RANDOM_UNIFORM 1
===

And even -DHAVE_CONFIG_H is supplied during the build:
===
cc -DHAVE_CONFIG_H -I. -I../../common  -I../../common  -I../../common  
-I./include  -I./include  -I/usr/local/include  -I/usr/local/include/libxml2 
-I/usr/l
ocal/include -O2 -pipe -Wall -Wextra -pthread -MT ksm_policy.o -MD -MP -MF 
.deps/ksm_policy.Tpo -c -o ksm_policy.o ksm_policy.c
===

However, I finally noticed config.h is never included in ksm_policy.c. I tried
doing so before the current #include lines as is done in other files, and it
made the warning disappear.

There was one more random-related warning:

===
notify.o(.text+0x233): In function `notify_setup':^M
: warning: random() isn't random; consider using arc4random()^M
===

The call in signer/src/wire/notify.c:
random()%(extra-base);

I guess #ifdef'ing this with HAVE_ARC4RANDOM like is done in ksm_policy.c
would be nice.

Next up some strcat stuff:

===
../ksm/libksm.a(datetime.o)(.text+0x961): In function `DtAppendTime':
: warning: strcat() is almost always misused, please use strlcat()
===

The DtAppendTime() function in enforcer/ksm/datetime.c contains six
calls to strcat, I dont feel comfortable converting these to strlcat, in
case i introduce bugs myself. Input is welcome though.

And another instance:

===
kc_helper.o(.text+0x677): In function `StrAppend':
: warning: strcat() is almost always misused, please use strlcat()
===

... the call in enforcer/utils/kc_helper.c:
strcat(*str1, str2);

Same thing applies here. Input is welcome.

Finally some unused variables, might as well be complete while I am at
it:

===
daemon/cmdhandler.c:398: warning: unused variable 'task'

shared/duration.c:442: warning: 'is_leap_year' defined but not used
shared/duration.c:449: warning: 'leap_days' defined but not used

shared/hsm.c:224: warning: unused variable 'retries'
shared/hsm.c:220: warning: unused variable 'status'
===

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-19 Thread Jérémie Courrèges-Anglas
Patrik Lundin patrik.lundin@gmail.com writes:

 On Sun, May 18, 2014 at 07:24:00PM +0200, Patrik Lundin wrote:
 
 First up is this one:
 ===
 pin.c: In function 'hsm_shm_open':
 pin.c:209: warning: comparison between signed and unsigned
 ===
 
 Next we have this one:
 ===
 hsmspeed.c:38:1: warning: PTHREAD_THREADS_MAX redefined
 In file included from hsmspeed.c:33:
 /usr/include/pthread.h:55:1: warning: this is the location of the
 previous definition
 ===
 
 Third and final (for now):
 ===
 hsmspeed.c: In function 'sign':
 hsmspeed.c:120: warning: control reaches end of non-void function
 ===
 

 Jerry Lundström from the OpenDNSSEC-team has been kind enough to create
 a branch where he fixed the stuff I posted above, and made it into a pull
 request:
 https://github.com/opendnssec/opendnssec/pull/83

 I have imported the changes as patches and those warnings are now gone.

 Since they have been sorted out I'll now go through the the rest of the
 warnings. Since upstream is watching I will be as verbose as possible.

 First of all there are a bunch of libraries spitting out warnings on several
 locations, I consider these outside the scope:

 ===
 .libs/libxml2.so.15.1: warning: strcpy() is almost always misused, please use 
 strlcpy()
 .libs/libxml2.so.15.1: warning: rand_r() isn't random; consider using 
 arc4random()
 .libs/libldns.so.6.1: warning: random() isn't random; consider using 
 arc4random()
 .libs/libxml2.so.15.1: warning: strcat() is almost always misused, please use 
 strlcat()
 ===

They are indeed outside the scope of this port.

 Now for the first warning in the code at hand:

 ../ksm/libksm.a(datetime.o)(.text+0x562): In function `DtSecondsInterval':
 : warning: strcpy() is almost always misused, please use strlcpy()

 The code looks like this:
 enforcer/ksm/datetime.c:
 charbuffer[64];
 [...]
 else {
 strcpy(buffer, 0s);
 }

 I am not sure trying to turn this into strlcpy is worth it since the
 string is static and the buffer obviously large enough. (Though I
 welcome cluebats from anyone more well versed in C here).

It is not about this particular occurrence.  If you replace it by
a strlcpy call, you will probably see the same warning, coming from
another strcpy call elsewhere.

Propose upstream strl* and snprintf as alternatives to the unchecked
functions.  If upstream sees interest in this, then a careful audit of
the code can follow, and strl* functions make error checking easier.
Adding fallback code for OSes not providing those functions is easy too.

 Next up some random warnings:

 ===
 ../ksm/libksm.a(ksm_policy.o)(.text+0xd31): In function `KsmPolicyUpdateSalt':
 : warning: rand() isn't random; consider using arc4random()
 ../ksm/libksm.a(ksm_policy.o)(.text+0xd13): In function `KsmPolicyUpdateSalt':
 : warning: srand() seed choices are invariably poor
 ===

 Now these warnings were interesting, looking into the code it looks like
 this:

 enforcer/ksm/ksm_policy.c:
 ===
 #ifdef HAVE_ARC4RANDOM
 for (i = 0; i  2*(policy-denial-saltlength); i++) {
 salt[i] = hex_chars[arc4random()%strlen(hex_chars)];
 }
 #else
 srand( time(NULL) );
 for (i = 0; i  2*(policy-denial-saltlength); i++) {
 salt[i] = hex_chars[rand()%strlen(hex_chars)];
 }
 #endif
 ===

 It is obviously prepared to use arc4random() if it is available, yet it does
 not for some reason.

 I found HAVE_ARC4RANDOM is indeed set:
 common/config.h:
 ===
 /* Define to 1 if you have the `arc4random' function. */
 #define HAVE_ARC4RANDOM 1

 /* Define to 1 if you have the `arc4random_uniform' function. */
 #define HAVE_ARC4RANDOM_UNIFORM 1
 ===

 And even -DHAVE_CONFIG_H is supplied during the build:
 ===
 cc -DHAVE_CONFIG_H -I. -I../../common  -I../../common  -I../../common  
 -I./include  -I./include  -I/usr/local/include  -I/usr/local/include/libxml2 
 -I/usr/l
 ocal/include -O2 -pipe -Wall -Wextra -pthread -MT ksm_policy.o -MD -MP -MF 
 .deps/ksm_policy.Tpo -c -o ksm_policy.o ksm_policy.c
 ===

 However, I finally noticed config.h is never included in ksm_policy.c. I tried
 doing so before the current #include lines as is done in other files, and it
 made the warning disappear.

Cool.

 There was one more random-related warning:

 ===
 notify.o(.text+0x233): In function `notify_setup':^M
 : warning: random() isn't random; consider using arc4random()^M
 ===

 The call in signer/src/wire/notify.c:
 random()%(extra-base);

 I guess #ifdef'ing this with HAVE_ARC4RANDOM like is done in ksm_policy.c
 would be nice.

See arc4random_uniform(3), the configure seems to test for its presence.

 Next up some strcat stuff:

 ===
 ../ksm/libksm.a(datetime.o)(.text+0x961): In function `DtAppendTime':
 : warning: strcat() is almost always misused, please use strlcat()
 ===

 The DtAppendTime() function in enforcer/ksm/datetime.c contains six
 calls to strcat, I dont feel comfortable converting these to strlcat, in
 case i introduce 

Re: opendnssec and softhsm revisited

2014-05-18 Thread Patrik Lundin
On Wed, May 07, 2014 at 10:57:50PM +0200, Patrik Lundin wrote:
 
 The opendnssec port is a work in progress. The most annoying thing
 while building currently is the warnings regarding comma at end of
 enumerator list which seems to be the result of inconsistent use of
 -std=c99 which i am not sure how to solve properly.
 

Trying to figure out what is the best course of action to remove these
warnings I am first of all trying to figure out why they are thrown on
OpenBSD but not on a Ubuntu 14.04 system that I use for comparision.

It seems to me it comes down to some sort of special handling of
included headers on the Ubuntu box that I do not see on OpenBSD.

Basically i see this:

On OpenBSD using the system include syntax:

# echo '#include ldns/error.h'  test.c
# cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c  
In file included from test.c:1:
/usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list

On OpenBSD including the file directly:

# echo '#include /usr/local/include/ldns/error.h'  test.c
# cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c
In file included from test.c:1:
/usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list

These are consistent. However, when looking at what happens on Ubuntu:

... Using system include syntax makes it quiet:

# echo '#include ldns/error.h'  test.c
# cc -pedantic -Wall -Wextra -c test.c

... while including the file directly causes a warning:

# echo '#include /usr/include/ldns/error.h'  test.c
# cc -pedantic -Wall -Wextra -c test.c
In file included from test.c:1:0:
/usr/include/ldns/error.h:129:28: warning: comma at end of enumerator list 
[-Wpedantic]
  LDNS_STATUS_RDATA_OVERFLOW,
^
I'm guessing this is the reason it is not spotted as easily on Linux.
What I wonder is if anyone here has struggled with a similar problem and
if there is a good solution for it.

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-18 Thread Stuart Henderson
This is due to differences between C compilers. gcc 4.8 and clang don't
warn for this with -pedantic, gcc 4.2.1 does.

I think -pedantic is fairly pointless in ports and should be removed,
but I would also report it to nlnetlabs as an ldns bug, I think the best
approach would be to remove the surplus , for better compiler compatibility
(and their other enums don't have a trailing ,).

https://www.nlnetlabs.nl/bugs-script/buglist.cgi?product=ldnsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcmdtype=doit

$ for i in clang egcc cc; do echo = $i; $i --version | head -1; $i -I 
/usr/local/include -pedantic -Wall -Wextra -c test
= clang
clang version 3.5 (trunk)
= egcc
egcc (GCC) 4.8.2
= cc
cc (GCC) 4.2.1 20070719 
In file included from test.c:1:
/usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list



On 2014/05/18 11:43, Patrik Lundin wrote:
 On Wed, May 07, 2014 at 10:57:50PM +0200, Patrik Lundin wrote:
  
  The opendnssec port is a work in progress. The most annoying thing
  while building currently is the warnings regarding comma at end of
  enumerator list which seems to be the result of inconsistent use of
  -std=c99 which i am not sure how to solve properly.
  
 
 Trying to figure out what is the best course of action to remove these
 warnings I am first of all trying to figure out why they are thrown on
 OpenBSD but not on a Ubuntu 14.04 system that I use for comparision.
 
 It seems to me it comes down to some sort of special handling of
 included headers on the Ubuntu box that I do not see on OpenBSD.
 
 Basically i see this:
 
 On OpenBSD using the system include syntax:
 
 # echo '#include ldns/error.h'  test.c
 # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c  
 In file included from test.c:1:
 /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list
 
 On OpenBSD including the file directly:
 
 # echo '#include /usr/local/include/ldns/error.h'  test.c
 # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c
 In file included from test.c:1:
 /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list
 
 These are consistent. However, when looking at what happens on Ubuntu:
 
 ... Using system include syntax makes it quiet:
 
 # echo '#include ldns/error.h'  test.c
 # cc -pedantic -Wall -Wextra -c test.c
 
 ... while including the file directly causes a warning:
 
 # echo '#include /usr/include/ldns/error.h'  test.c
 # cc -pedantic -Wall -Wextra -c test.c
 In file included from test.c:1:0:
 /usr/include/ldns/error.h:129:28: warning: comma at end of enumerator list 
 [-Wpedantic]
   LDNS_STATUS_RDATA_OVERFLOW,
 ^
 I'm guessing this is the reason it is not spotted as easily on Linux.
 What I wonder is if anyone here has struggled with a similar problem and
 if there is a good solution for it.
 
 Regards,
 Patrik Lundin
 



Re: opendnssec and softhsm revisited

2014-05-18 Thread Patrik Lundin
On Sun, May 18, 2014 at 11:04:19AM +0100, Stuart Henderson wrote:
 This is due to differences between C compilers. gcc 4.8 and clang don't
 warn for this with -pedantic, gcc 4.2.1 does.
 
 I think -pedantic is fairly pointless in ports and should be removed,
 but I would also report it to nlnetlabs as an ldns bug, I think the best
 approach would be to remove the surplus , for better compiler compatibility
 (and their other enums don't have a trailing ,).
 

Thank you for the input, this has been reported here:
https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=579

I guess I will have to look into how to disabled -pedantic in the build
then.

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-18 Thread Patrik Lundin
On Sun, May 18, 2014 at 01:24:11PM +0200, Patrik Lundin wrote:
 
 I guess I will have to look into how to disabled -pedantic in the build
 then.
 

Disabling -pedantic was easy to do at configure time, using
--disable-pedantic. Now I have started looking at the remaining
warnings.

I am constantly debating with myself which group I should talk to first
regarding the following questions, but since these are not thrown on
the comparision Linux box I'll start in this end:

First up is this one:
===
pin.c: In function 'hsm_shm_open':
pin.c:209: warning: comparison between signed and unsigned
===

This is caused by comparing a size_t variable to shm_segsz which
according to shmctl(2) on OpenBSD is an int. Reading the same man page
on the Ubuntu box shows that shm_segsz is considerd to be type size_t
there.

I guess I can fix this by casting shm_segsz to an unsigned int, does
that sound reasonable?

Next we have this one:
===
hsmspeed.c:38:1: warning: PTHREAD_THREADS_MAX redefined
In file included from hsmspeed.c:33:
/usr/include/pthread.h:55:1: warning: this is the location of the
previous definition
===

It seems the Linux box just has this to say:
/* We have no predefined limit on the number of threads.  */
#undef PTHREAD_THREADS_MAX

While OpenBSD sets it to a very big value:
#define PTHREAD_THREADS_MAX ULONG_MAX

The code itself sets it to 2048, way less than the default. I guess
having a more conservative setting is not a problem. Maby I should just
leave this warning as is?

Third and final (for now):
===
hsmspeed.c: In function 'sign':
hsmspeed.c:120: warning: control reaches end of non-void function
===

This warning bothers me somewhat, the function is declared in the
following way:
void * sign (void *arg)

It is passed to pthread_create() which is probably why it is a pointer
function.  

I am not sure why the Linux box does not say anything about this. My
current idea is that the function should just have a dummy return
NULL; after the call to pthread_exit(). Any ideas?

Regards,
Patrik Lundin



Re: opendnssec and softhsm revisited

2014-05-08 Thread Patrik Lundin
On Wed, May 07, 2014 at 11:23:52PM +0100, Stuart Henderson wrote:
 Some quick comments from a read-through of the files (but
 not building/testing yet) :-
 
 opendnssec README:
 - should follow style from ports/infrastructure/templates/README.template

I have updated the README to reflect README.template.

 - vi /etc/softhsm.conf should use ${SYSCONFDIR},

Nice catch, this has been fixed in this version.

 and I think the directory
 structure and ownership should be setup with @samples rather than
 telling people what to type.

The reason i made those steps manual is because i was not sure how much
of a relationship I should enforce between the opendnssec and softhsm
packages. I do agree that solving it via PLIST is cleaner given that
having an empty softhsm/ directory is acceptable if not being used.

I have added the directory to PLIST and updated the README accordingly.
The file owner still needs to be set manually though, maby this can be
accomplished in a better way?

 
 opendnssec PLIST:
 - no point @sample'ing /var/run/opendnssec/, you need to create it in the
 rc_pre in the rc script anyway because /var/run is cleared at boot.
 example in smokeping.

The only reason I have added the @sample is because I wanted to make
'make update-plist' happy. Without the @sample i get a Bogus element
outside of every prefix warning.

Given that this is fine then OpenDNSSEC actually creates that directory
itself when started, so a rc_pre is not needed.

 - @owner/@group need updating

I'm not sure what you mean by this, what am I missing? :)

 - you're using /var/opendnssec/ in this file but ${LOCALSTATEDIR} in README
 
 softhsm PLIST:
 - /var / ${LOCALSTATEDIR}
 

Using ${LOCALSTATEDIR} in the PLISTs also cause Bogus element outside
of every prefix warnings, maby this is OK?

I have updated the PLISTs for now.

Thanks a lot for taking a look!

Regards,
Patrik Lundin


softhsm.tgz
Description: application/tar-gz


opendnssec.tgz
Description: application/tar-gz


Re: opendnssec and softhsm revisited

2014-05-07 Thread Stuart Henderson
On 2014/05/07 22:57, Patrik Lundin wrote:
 Hello,
 
 I thought I would take a second look at porting opendnssec and softhsm
 since last time my softhsm adventure grinded to a halt due to libtool
 issues
 (http://marc.info/?l=openbsd-portsm=137054816021002w=2).
 
 The attached softhsm port is based on what sthen@ sent out in that
 thread with some stuff removed.  I am not sure if it is because of the
 recent libtool work I have seen on the lists, but it now seems the
 softhsm shared object turns up just fine without any special care.
 
 The opendnssec port is a work in progress. The most annoying thing
 while building currently is the warnings regarding comma at end of
 enumerator list which seems to be the result of inconsistent use of
 -std=c99 which i am not sure how to solve properly.
 
 Another thing I am not sure about is the MODULES=
 converters/libiconv which I added because portcheck wanted it to be
 there.
 
 Finally I am pretty sure both LICENSE files can be summed up as BSD, an
 extra pair of eyes would be welcome though. I make sure they are
 installed under doc/name in both ports.
 
 Anyway, any feedback is much appreciated.
 
 Regards,
 Patrik Lundin


Some quick comments from a read-through of the files (but
not building/testing yet) :-

opendnssec README:
- should follow style from ports/infrastructure/templates/README.template
- vi /etc/softhsm.conf should use ${SYSCONFDIR}, and I think the directory
structure and ownership should be setup with @samples rather than
telling people what to type.

opendnssec PLIST:
- no point @sample'ing /var/run/opendnssec/, you need to create it in the
rc_pre in the rc script anyway because /var/run is cleared at boot.
example in smokeping.
- @owner/@group need updating
- you're using /var/opendnssec/ in this file but ${LOCALSTATEDIR} in README

softhsm PLIST:
- /var / ${LOCALSTATEDIR}