tincctl on *BSD

Hi all,

*BSDs and OSX do net seem to support SO_PEERCRED. Checking for that  
is needed in src/tincctl.c.

--- src/tincctl.c       (revision 1555)
+++ src/tincctl.c       (working copy)
 <at>  <at>  -399,6 +399,7  <at>  <at> 
                 return 1;
         }

+#ifdef SO_PEERCRED
         struct ucred cred;
         socklen_t credlen = sizeof cred;

 <at>  <at>  -411,6 +412,7  <at>  <at> 
                 printf("%d\n", cred.pid);
                 return 0;
         }
+#endif

         if(!strcasecmp(argv[optind], "stop")) {
                 write(fd, "stop\n", 5);

Hi all,

*BSDs and OSX do net seem to support SO_PEERCRED. Checking for that  
is needed in src/tincctl.c.

other crypto apis

Hi

I'd like to make tincd work with other crypto apis than openssl/ 
libcrypt. I've learned from the subversion repository that an effort  
was started to port it to gnu-tls. I for myself would like to get  
tincd linking against xyssl (1) because it is very lightweight and  
thus an adequate option on devices with little memory and disk/flash  
space, i.e. embedded systems. Now i'm browsing the sourcecode from  
1.1 branch and i'm tempted to isolate everything which is looking  
like crypto stuff to a separate file and defining some wrapper  
functions resulting in an abstraction layer.

 From 2.0 README i learn that openssl should be dropped in favour of  
gnutls and gnucrypt. I think this might be a good chance to  
modularize this part of tinc, so poeple/distributors may choose from  
different crypto/auth backends.

Now my two questions:
- Is it worth investing a great effort into tinc 1.1 and create some  
abstraction layer?
- Any chances to get something like this into 2.0? Is this branch  
already in active development or is it a still stub?

Cheers,
Lorenz

Hi

Re: other crypto apis

On 02.09.2007, at 15:25, Lorenz Schori wrote:

> - Is it worth investing a great effort into tinc 1.1 and create  
> some abstraction layer?
>

Silly me, i was looking at trunk. The crypt abstraction is already  
done in 1.1. Great!

On 02.09.2007, at 15:25, Lorenz Schori wrote:

> - Is it worth investing a great effort into tinc 1.1 and create  
> some abstraction layer?
>

Silly me, i was looking at trunk. The crypt abstraction is already  
done in 1.1. Great!

Re: other crypto apis

On Sun, Sep 02, 2007 at 03:25:44PM +0200, Lorenz Schori wrote:

> I'd like to make tincd work with other crypto apis than openssl/libcrypt. 
> I've learned from the subversion repository that an effort was started to 
> port it to gnu-tls. I for myself would like to get tincd linking against 
> xyssl (1) because it is very lightweight and thus an adequate option on 
> devices with little memory and disk/flash space, i.e. embedded systems. Now 
> i'm browsing the sourcecode from 1.1 branch and i'm tempted to isolate 
> everything which is looking like crypto stuff to a separate file and 
> defining some wrapper functions resulting in an abstraction layer.
>
> From 2.0 README i learn that openssl should be dropped in favour of gnutls 
> and gnucrypt. I think this might be a good chance to modularize this part 
> of tinc, so poeple/distributors may choose from different crypto/auth 
> backends.
>
> Now my two questions:
> - Is it worth investing a great effort into tinc 1.1 and create some 
> abstraction layer?

Yes, but most of the abstraction is already done. Just make a new
directory src/xyssl/, and copy the files from src/gcrypt/. Then you just
need to change those files to use xyssl instead of libgcrypt. The
function declarations in the header files must be the same, but you can
change the structures (rsa_t and digest_t).

> - Any chances to get something like this into 2.0? Is this branch already 
> in active development or is it a still stub?

2.0 was supposed to be a complete reimplementation. However, it was

Re: other crypto apis

On 02.09.2007, at 16:06, Guus Sliepen wrote:

> Yes, but most of the abstraction is already done. Just make a new
> directory src/xyssl/, and copy the files from src/gcrypt/. Then you  
> just
> need to change those files to use xyssl instead of libgcrypt. The
> function declarations in the header files must be the same, but you  
> can
> change the structures (rsa_t and digest_t).

hm... blowfish/ofb seems to be required by the protocol. It's not  
implemented in xyssl. I probably have to look at that first...

On 02.09.2007, at 16:06, Guus Sliepen wrote:

> Yes, but most of the abstraction is already done. Just make a new
> directory src/xyssl/, and copy the files from src/gcrypt/. Then you  
> just
> need to change those files to use xyssl instead of libgcrypt. The
> function declarations in the header files must be the same, but you  
> can
> change the structures (rsa_t and digest_t).

hm... blowfish/ofb seems to be required by the protocol. It's not  
implemented in xyssl. I probably have to look at that first...

Re: other crypto apis

On 02.09.2007, at 16:06, Guus Sliepen wrote:

> Yes, but most of the abstraction is already done. Just make a new
> directory src/xyssl/, and copy the files from src/gcrypt/. Then you  
> just
> need to change those files to use xyssl instead of libgcrypt. The
> function declarations in the header files must be the same, but you  
> can
> change the structures (rsa_t and digest_t).
>

hm... blowfish/ofb seems to be required by the protocol. It's not  
implemented in xyssl. I probably have to look at that first...

On 02.09.2007, at 16:06, Guus Sliepen wrote:

> Yes, but most of the abstraction is already done. Just make a new
> directory src/xyssl/, and copy the files from src/gcrypt/. Then you  
> just
> need to change those files to use xyssl instead of libgcrypt. The
> function declarations in the header files must be the same, but you  
> can
> change the structures (rsa_t and digest_t).
>

hm... blowfish/ofb seems to be required by the protocol. It's not  
implemented in xyssl. I probably have to look at that first...

Re: other crypto apis

On Sun, Sep 02, 2007 at 04:15:57PM +0200, Lorenz Schori wrote:

>> Yes, but most of the abstraction is already done. Just make a new
>> directory src/xyssl/, and copy the files from src/gcrypt/. Then you just
>> need to change those files to use xyssl instead of libgcrypt. The
>> function declarations in the header files must be the same, but you can
>> change the structures (rsa_t and digest_t).
>
> hm... blowfish/ofb seems to be required by the protocol. It's not 
> implemented in xyssl. I probably have to look at that first...

libgcrypt also lacks OFB support. But maybe we can write a small routine
that does the OFB part, and then feeds that to gcrypt/xyssl in ECB mode.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

On Sun, Sep 02, 2007 at 04:15:57PM +0200, Lorenz Schori wrote:

>> Yes, but most of the abstraction is already done. Just make a new
>> directory src/xyssl/, and copy the files from src/gcrypt/. Then you just
>> need to change those files to use xyssl instead of libgcrypt. The
>> function declarations in the header files must be the same, but you can
>> change the structures (rsa_t and digest_t).
>
> hm... blowfish/ofb seems to be required by the protocol. It's not 
> implemented in xyssl. I probably have to look at that first...

Re: tincctl on *BSD

Lorenz Schori wrote:
> Hi all,
> 
> *BSDs and OSX do net seem to support SO_PEERCRED. Checking for that is
> needed in src/tincctl.c.

Those systems do support peer credentials, though not the pid field
specifically.

We had a discussion about this a while ago - I would prefer to satisfy
the security constraint without SO_PEERCRED by putting the socket in a
directory of appropriately tight permissions. IIRC, Guus would prefer to
use peer credentials where available even so.

> 
> 
> --- src/tincctl.c       (revision 1555)
> +++ src/tincctl.c       (working copy)
>  <at>  <at>  -399,6 +399,7  <at>  <at> 
>                 return 1;
>         }
> 
> +#ifdef SO_PEERCRED
>         struct ucred cred;
>         socklen_t credlen = sizeof cred;
> 
>  <at>  <at>  -411,6 +412,7  <at>  <at> 
>                 printf("%d\n", cred.pid);
>                 return 0;
>         }