![[en]](/_images/EN_flag_small.gif){kind=small}
![[us]](/_images/US_flag_small.gif){kind=small}
![[fr]](/_images/FR_flag_small.gif){kind=small}
#0x3a: Gilles: Ghaza
Tue, 27 07 2010 22:06, gilles@
Be it for OpenBSD, smtpd, poolp or random hacks, most of my post are related to computer science somehow.
I also happen to be a musician and after moving out from Paris and leaving my band there, I decided to try and join or start a few projects here in Nantes. One of these project is a solo project which I am currently working on...
First tune to be released, Ghaza, was inspired by the death of 9 activists on the Marvi Marmara, in 2010.
Feel free to download, share and let me know if you like it. I have a webpage at My Major Company, should you want to sponsor me ;-)
___
Tue, 27 07 2010 22:06, gilles@
Be it for OpenBSD, smtpd, poolp or random hacks, most of my post are related to computer science somehow.
I also happen to be a musician and after moving out from Paris and leaving my band there, I decided to try and join or start a few projects here in Nantes. One of these project is a solo project which I am currently working on...
First tune to be released, Ghaza, was inspired by the death of 9 activists on the Marvi Marmara, in 2010.
Feel free to download, share and let me know if you like it. I have a webpage at My Major Company, should you want to sponsor me ;-)
___
#0x39: PCT: Poolp Crypto Toolkit
Mon, 26 07 2010 21:02, gilles@
I have renamed the nbpg project into PCT, which stands for Poolp Crypto Toolkit.
Not so many visible improvements, I did quite a bit of cleanup and wrote a small allocator which relies on mmap() and will help me spot bugs and general memory usage. It also allows for a complete wipe of allocated chunks preventing informations leak in case of a memory leak or in case a *common* error path is followed.
[...]
p1 = pctalloc(1, sizeof(*p));
p2 = pctalloc(1, sizeof(*p));
p3 = pctalloc(1, sizeof(*p));
p4 = pctalloc(1, sizeof(*p));
pctfree(p1); // zeroes and releases p1
pctwipe(); // zeroes and releases ALL allocated chunks
[...]
___
Mon, 26 07 2010 21:02, gilles@
I have renamed the nbpg project into PCT, which stands for Poolp Crypto Toolkit.
Not so many visible improvements, I did quite a bit of cleanup and wrote a small allocator which relies on mmap() and will help me spot bugs and general memory usage. It also allows for a complete wipe of allocated chunks preventing informations leak in case of a memory leak or in case a *common* error path is followed.
[...]
p1 = pctalloc(1, sizeof(*p));
p2 = pctalloc(1, sizeof(*p));
p3 = pctalloc(1, sizeof(*p));
p4 = pctalloc(1, sizeof(*p));
pctfree(p1); // zeroes and releases p1
pctwipe(); // zeroes and releases ALL allocated chunks
[...]
___
#0x38: nbpg moving forward
Fri, 23 07 2010 20:37, gilles@
I had temporarily paused nbpg development because I was facing a bug that I did not have much time to investigate.
Whenever parsing a Compressed Data Packet, nbpg would successfully extract the data but fail to inflate it with a data format error. No matter what I tried, I could not figure out what was wrong with my code or with the data.
Turns out that I had to rely on an undocumented feature of zlib. I discovered it when I gave up at trying to make RFC interpretations and looking at what the GnuPG guys did. I saw the following comment in their compress.c:
* PGP uses a windowsize of 13 bits.
* it forces zlib not to expect a zlib header. This is a
* undocumented feature Peter Gutmann told me about.
After doing a one line diff to nbpg I managed to extract a compress data packet. This allowed me to parse two new packets and I can now move things forward :-)
Output of a signed text file:
### 0x20cd54000: Compressed Data packet
length: 107
algorithm: ZIP
### 0x20cd54800: One-Pass Signature packet
length: 13
version: 3
type: Signature of a binary document
hash algorithm: SHA-1
public-key algorithm: DSA
keyid: F838AC47FA273AD7
nested: no
### 0x20cd55000: Literal Data packet
length: 19
type: binary data
filename: bleh.txt
flags: none
buffer: [test
]
### 0x20cd55c00: Signature packet
length: 70
version: 4
type: Signature of a binary document
public key algorithm: DSA
hash algorithm: SHA-1
size of hashed area: 6
size of unhashed area: 10
___
Fri, 23 07 2010 20:37, gilles@
I had temporarily paused nbpg development because I was facing a bug that I did not have much time to investigate.
Whenever parsing a Compressed Data Packet, nbpg would successfully extract the data but fail to inflate it with a data format error. No matter what I tried, I could not figure out what was wrong with my code or with the data.
Turns out that I had to rely on an undocumented feature of zlib. I discovered it when I gave up at trying to make RFC interpretations and looking at what the GnuPG guys did. I saw the following comment in their compress.c:
* PGP uses a windowsize of 13 bits.
* it forces zlib not to expect a zlib header. This is a
* undocumented feature Peter Gutmann told me about.
After doing a one line diff to nbpg I managed to extract a compress data packet. This allowed me to parse two new packets and I can now move things forward :-)
Output of a signed text file:
### 0x20cd54000: Compressed Data packet
length: 107
algorithm: ZIP
### 0x20cd54800: One-Pass Signature packet
length: 13
version: 3
type: Signature of a binary document
hash algorithm: SHA-1
public-key algorithm: DSA
keyid: F838AC47FA273AD7
nested: no
### 0x20cd55000: Literal Data packet
length: 19
type: binary data
filename: bleh.txt
flags: none
buffer: [test
]
### 0x20cd55c00: Signature packet
length: 70
version: 4
type: Signature of a binary document
public key algorithm: DSA
hash algorithm: SHA-1
size of hashed area: 6
size of unhashed area: 10
___
#0x37: I ain't slackin'
Thu, 22 07 2010 23:19, gilles@
On the poolp.org side, work in progress and quite busy with contracters.
On the smtpd side, poolp's setup has gone through a bit of yacc cleanup mostly. I had tried to do some useful work in the maps and auth area, but I ran into the wall as I realized that jacekm@'s queue code no longer uses struct mxrelay preventing me from passing useful information from MTA to lookup process. I'm trying to figure out a way that would not involve very invasive changes and diverging too much from the OpenBSD tree but it looks like I won't be left with much choice and very soon my diffs will no longer apply to the OpenBSD tree.
My main goal right now is to get authentication backed by maps, be it for smtp or mta authentication. This would allow authentication of virtual users through a LDAP server and pave the way to hosting a fully-virtual mail service backed by no single system account.
The nbpg project hasn't seen a commit in weeks, I'm stuck with a deflate bug I have not sorted out yet. I must admit I was busy so I didn't investigate for more than a few hours, will try to get it fixed soon.
Finally, I started looking at Android ROMS a couple days ago and started working on my own ROM. Nothing very fancy at the moment, it is basically the latest official image with many packages that annoy me removed. I have some poolp related plans, I'll talk about them when they are a bit more real :-)
___
Thu, 22 07 2010 23:19, gilles@
On the poolp.org side, work in progress and quite busy with contracters.
On the smtpd side, poolp's setup has gone through a bit of yacc cleanup mostly. I had tried to do some useful work in the maps and auth area, but I ran into the wall as I realized that jacekm@'s queue code no longer uses struct mxrelay preventing me from passing useful information from MTA to lookup process. I'm trying to figure out a way that would not involve very invasive changes and diverging too much from the OpenBSD tree but it looks like I won't be left with much choice and very soon my diffs will no longer apply to the OpenBSD tree.
My main goal right now is to get authentication backed by maps, be it for smtp or mta authentication. This would allow authentication of virtual users through a LDAP server and pave the way to hosting a fully-virtual mail service backed by no single system account.
The nbpg project hasn't seen a commit in weeks, I'm stuck with a deflate bug I have not sorted out yet. I must admit I was busy so I didn't investigate for more than a few hours, will try to get it fixed soon.
Finally, I started looking at Android ROMS a couple days ago and started working on my own ROM. Nothing very fancy at the moment, it is basically the latest official image with many packages that annoy me removed. I have some poolp related plans, I'll talk about them when they are a bit more real :-)
___
#0x36: smtpd update on poolp.org
Wed, 21 07 2010 18:43, gilles@
I have just updated smtpd on poolp.org with a fresh checkout from poolp's repository.
The smtpd that runs has the code to support per-rule queue expiry, ldap lookups as well as a fix for a DoS that was introduced by the new queue code jacekm@ wrote.
Basically, smtpd fatals() when it fails to deliver a bounce locally, unfortunately this may happen for many legitimate reasons so smtpd on poolp.org treats a failed bounce delivery just as a successful delivery.
___
Wed, 21 07 2010 18:43, gilles@
I have just updated smtpd on poolp.org with a fresh checkout from poolp's repository.
The smtpd that runs has the code to support per-rule queue expiry, ldap lookups as well as a fix for a DoS that was introduced by the new queue code jacekm@ wrote.
Basically, smtpd fatals() when it fails to deliver a bounce locally, unfortunately this may happen for many legitimate reasons so smtpd on poolp.org treats a failed bounce delivery just as a successful delivery.
___
#0x35: smtpd support for ldap... it's alive !
Tue, 20 07 2010 14:06, gilles@
I have spent yesterday's evening fighting with aldap.c and ber.c trying to figure out if I was the one doing something wrong or if there was a bug in either of these files.
Turns out that there were two bugs, one caused by a wrong BER class in aldap.c causing ldapd to reject the request. I discussed the issue with martinh@ who came up with a fix in only a few minutes :-)
The other bug caused the lookup process in smtpd to segfault when a match was found. I traced back the issue back to aldap.c:aldap_get_stringset() which had a NULL-deref.
smtpd can now lookup through ldapd. The following example shows an aliases lookup, but ldap can be used in place of any map which means virtualhosts and secrets map may rely on it.
This is initial support, not optimized, not asynchronous and with connect/bind for each lookup. work in progress.
Below is a sample config with a test session log:
-- smtpd.conf ----
listen on lo0
ldap "local" "ldap://localhost:389" "cn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "local" "dc=poolp,dc=org" "(&(objectclass=sendmailMTAAlias)(sendmailMTAKey=%k))" "sendmailMTAAliasValue" }
accept for local alias "aliases" deliver to mbox
accept for all relay
-- smtpd.conf ----
-- smtpd -dv output----
smtp_new: incoming client on listener: 0x20a1ea000
lookup_ptr IPv6:::1
lookup_ptr success
session_pickup: greeting client
command: EHLO args: L
command: MAIL FROM args:
command: RCPT TO args:
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4480
smtpd: map_ldap_get: aldap: 0x20c1b4480
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=root))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
smtpd: map_ldap_get: found: gilles,gilles@epitech.net
aliases_exist: 'root' exists with 2 expansion nodes
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4180
smtpd: map_ldap_get: aldap: 0x20c1b4180
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=root))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
smtpd: map_ldap_get: found: gilles,gilles@epitech.net
aliases_get: returned 2 aliases
lka_resolve_node: node is local username: gilles
lka_resolve_node: resolved to address: gilles@sparc64.poolp.org
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4700
smtpd: map_ldap_get: aldap: 0x20c1b4700
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=gilles))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
lka_resolve_node: node is address: gilles@epitech.net
aux R|gilles@openbsd.org|root@localhost||gilles@epitech.net|smtp.poolp.org||starttls||
aux M|gilles@openbsd.org|root@localhost||gilles|/var/mail/gilles
-- smtpd -dv output----
___
Tue, 20 07 2010 14:06, gilles@
I have spent yesterday's evening fighting with aldap.c and ber.c trying to figure out if I was the one doing something wrong or if there was a bug in either of these files.
Turns out that there were two bugs, one caused by a wrong BER class in aldap.c causing ldapd to reject the request. I discussed the issue with martinh@ who came up with a fix in only a few minutes :-)
The other bug caused the lookup process in smtpd to segfault when a match was found. I traced back the issue back to aldap.c:aldap_get_stringset() which had a NULL-deref.
smtpd can now lookup through ldapd. The following example shows an aliases lookup, but ldap can be used in place of any map which means virtualhosts and secrets map may rely on it.
This is initial support, not optimized, not asynchronous and with connect/bind for each lookup. work in progress.
Below is a sample config with a test session log:
-- smtpd.conf ----
listen on lo0
ldap "local" "ldap://localhost:389" "cn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "local" "dc=poolp,dc=org" "(&(objectclass=sendmailMTAAlias)(sendmailMTAKey=%k))" "sendmailMTAAliasValue" }
accept for local alias "aliases" deliver to mbox
accept for all relay
-- smtpd.conf ----
-- smtpd -dv output----
smtp_new: incoming client on listener: 0x20a1ea000
lookup_ptr IPv6:::1
lookup_ptr success
session_pickup: greeting client
command: EHLO args: L
command: MAIL FROM args:
command: RCPT TO args:
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4480
smtpd: map_ldap_get: aldap: 0x20c1b4480
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=root))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
smtpd: map_ldap_get: found: gilles,gilles@epitech.net
aliases_exist: 'root' exists with 2 expansion nodes
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4180
smtpd: map_ldap_get: aldap: 0x20c1b4180
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=root))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
smtpd: map_ldap_get: found: gilles,gilles@epitech.net
aliases_get: returned 2 aliases
lka_resolve_node: node is local username: gilles
lka_resolve_node: resolved to address: gilles@sparc64.poolp.org
smtpd: map_ldap_open: found ldapserver 'local' in smtpd.conf
smtpd: map_ldap_open: ldap server accepted credentials
smtpd: map_ldap_open: aldap: 0x20c1b4700
smtpd: map_ldap_get: aldap: 0x20c1b4700
smtpd: map_ldap_get: basedn: dc=poolp,dc=org
smtpd: map_ldap_get: filter: (&(objectclass=sendmailMTAAlias)(sendmailMTAKey=gilles))
smtpd: map_ldap_get: attribute: sendmailMTAAliasValue
lka_resolve_node: node is address: gilles@epitech.net
aux R|gilles@openbsd.org|root@localhost||gilles@epitech.net|smtp.poolp.org||starttls||
aux M|gilles@openbsd.org|root@localhost||gilles|/var/mail/gilles
-- smtpd -dv output----
___
#0x34: smtpd support for ldap delayed
Mon, 19 07 2010 19:41, gilles@
Just a quick post to mention that ldap support for poolp.org's smtpd has been delayed because of a bug I have not manage to fix yet.
Most of the code is written already, the bug just causes the ldap server to reject smtpd's request with an error I do not understand. Once I get past this and am able to retrieve the result, aliases and virtualhosts may be resolved from ldap out of the box.
smtpd.conf now looks like this:
[...]
ldap "local" "ldap://localhost:389" "cn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "local" "dc=poolp,dc=org" "(&(objectclass=smtpdAlias)(mapKey=%k))" "mapValue" }
accept for local alias "aliases" deliver to mbox
[...]
___
Mon, 19 07 2010 19:41, gilles@
Just a quick post to mention that ldap support for poolp.org's smtpd has been delayed because of a bug I have not manage to fix yet.
Most of the code is written already, the bug just causes the ldap server to reject smtpd's request with an error I do not understand. Once I get past this and am able to retrieve the result, aliases and virtualhosts may be resolved from ldap out of the box.
smtpd.conf now looks like this:
[...]
ldap "local" "ldap://localhost:389" "cn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "local" "dc=poolp,dc=org" "(&(objectclass=smtpdAlias)(mapKey=%k))" "mapValue" }
accept for local alias "aliases" deliver to mbox
[...]
___
#0x33: smtpd support for per-domain expiry and LDAP lookups
Thu, 15 07 2010 20:18, gilles@
Hi,
I have adapted to latest smtpd a diff from many weeks ago which brings support for per-domain messages expiry in queue.
Basically:
accept for domain "poolp.org" deliver to mbox expire 4d
will retain the message in queue for four days in case of a soft failure delivery attempt. It only allows for overriding the default expiry time for a specific domain.
The LDAP lookup code should be finished this Sunday as I won't have time to work on it prior to that.
Poolp's MX will be updated after that to start using ldapd as a backend for aliases resolution and eventually authentication if I manage to.
___
Thu, 15 07 2010 20:18, gilles@
Hi,
I have adapted to latest smtpd a diff from many weeks ago which brings support for per-domain messages expiry in queue.
Basically:
accept for domain "poolp.org" deliver to mbox expire 4d
will retain the message in queue for four days in case of a soft failure delivery attempt. It only allows for overriding the default expiry time for a specific domain.
The LDAP lookup code should be finished this Sunday as I won't have time to work on it prior to that.
Poolp's MX will be updated after that to start using ldapd as a backend for aliases resolution and eventually authentication if I manage to.
___
#0x32: Initial code for LDAP in poolp's smtpd
Mon, 12 07 2010 11:43, gilles@
Hi doodz,
Just a quick and short post to mention that I have started bringing ldap support to smtpd. It's not yet working but in a couple hours of work, I reached a state where I can define a set of ldap servers and credentials, tell smtpd to use a particular ldap server for a specific mapping (ie: aliases) and have smtpd connect and authenticate to the proper ldap server at runtime.
This was all done through a new backend to the map API, and the only part missing is the actual search for a key which will not be that hard to implement, I just didn't get the time to finish it yesterday.
I will try to find the time to get this done by the end of this week. Stay tuned.
-- smtpd.conf --
ldap "poolp" "ldap://ldap.poolp.org:389" "dn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "poolp" }
accept for local alias "aliases" deliver to mbox
accept for all relay
___
Mon, 12 07 2010 11:43, gilles@
Hi doodz,
Just a quick and short post to mention that I have started bringing ldap support to smtpd. It's not yet working but in a couple hours of work, I reached a state where I can define a set of ldap servers and credentials, tell smtpd to use a particular ldap server for a specific mapping (ie: aliases) and have smtpd connect and authenticate to the proper ldap server at runtime.
This was all done through a new backend to the map API, and the only part missing is the actual search for a key which will not be that hard to implement, I just didn't get the time to finish it yesterday.
I will try to find the time to get this done by the end of this week. Stay tuned.
-- smtpd.conf --
ldap "poolp" "ldap://ldap.poolp.org:389" "dn=root,dc=poolp,dc=org" "secret"
map "aliases" { source ldap "poolp" }
accept for local alias "aliases" deliver to mbox
accept for all relay
___
#0x31: Poolp: i-buddy for OpenBSD
Sat, 10 07 2010 23:26, gilles@
I borrowed this toy from my girlfriend and played a bit with it to get it to work on OpenBSD...
Sadly I had to cut the video short, the device started melting while I was bruteforcing actions ;-)
___
Sat, 10 07 2010 23:26, gilles@
I borrowed this toy from my girlfriend and played a bit with it to get it to work on OpenBSD...
Sadly I had to cut the video short, the device started melting while I was bruteforcing actions ;-)
___
![[openbsd]](/_images/pb-openbsd.png){kind=small}
![[apache]](/_images/pb-apache.png){kind=small}
![[python]](/_images/pb-python.png){kind=small}