Re: [dev] Suckless DNS server

[Jan Klemkow]

On Wed, 19 Jul 2023 16:42:58 +0200 (CEST), Sagar Acharya wrote:
> Please let us know authoritative and recursive DNS servers. 

I also use unbound and nsd in official setups, because its OpenBSD
default and I need to serve more than A and  records.

In testing setups I like dnsmasq, because it way easier to configure.
You don't have to deal with "complex" zone files.  dnsmasq just serves
the content of the /etc/hosts file.

Thus, from my suckless perspective I would recommend dnsmasq.  But, if
you need more than A/ records (e.g. for DNSSEC or Mailing) nsd is
fine.

bye,
Jan

Re: [dev] [ii] connect to servers with self signed tls certificates

[Jan Klemkow]

Hi Fernando,

On Sat, Oct 29, 2022 at 11:38:10AM -0500, fernandoreyesavila3 wrote:
> I am hosting an ergo irc server with self signed certificates.
> Connecting to any public irc server works as expected. ii prints the
> following when I try to connect to my server.
> 
> $ ii -s servername.com -p 6697
> NICK nando
> USER nando localhost servername.com :nando
> 
> ii: remote host closed connection: No such file or directory
> 
> I patched ii with tls encryption support and ran
> 
> $ ii -t -s servername.com -p 6697
> ii: tls_handshake: certificate verification failed: self signed certificate
> 
> I connected through hexchat by accepting invalid ssl certificates.
> Is there a similair option for ii? Any help would be appreciated.

I updated the tls-patch for ii.  Checkout the new fingerprint option.

Use it like this:

# ii -ts irc.example.com -p 6697 -F ""
ii: wrong fingerprint: 
SHA256:848f491d956befc9b9a79f1000a57b3eb131d424e4bae69b3684d4327fb11f02

# ii -ts irc.example.com -p 6697 -F 
SHA256:848f491d956befc9b9a79f1000a57b3eb131d424e4bae69b3684d4327fb11f02
NICK user
USER user localhost irc.example.com :user
...

Does this work for you?

bye,
Jan

Re: [dev] [ii] connect to servers with self signed tls certificates

[Jan Klemkow]

Hi Fernando and Hiltjo,

On Sat, Oct 29, 2022 at 08:18:22PM +0200, Hiltjo Posthuma wrote:
> On Sat, Oct 29, 2022 at 11:38:10AM -0500, fernandoreyesavila3 wrote:
> > I am hosting an ergo irc server with self signed certificates.
> > Connecting to any public irc server works as expected. ii prints the
> > following when I try to connect to my server.
> > 
> > $ ii -s servername.com -p 6697
> > NICK nando
> > USER nando localhost servername.com :nando
> > 
> > ii: remote host closed connection: No such file or directory
> > 
> > I patched ii with tls encryption support and ran
> > 
> > $ ii -t -s servername.com -p 6697
> > ii: tls_handshake: certificate verification failed: self signed certificate
> > 
> > I connected through hexchat by accepting invalid ssl certificates.
> > Is there a similair option for ii? Any help would be appreciated.
> 
> With LibreSSL libtls: you could set a certificate file:
> 
>   https://man.openbsd.org/tls_config_set_ca_file
> 
> Maybe you could add a command-line flag that allows to set this certificate 
> so it
> can be set per server.

For those use cases, I would just add a "don't check anything" flag.
The API of libtls is to detailed, to expose every knob as an option to
ii. Maybe an -F  option could be a compromise for selfsign
certs?!

I'll think about it and make a change to the tls patch.

Thanks,
Jan

Re: [dev] sshd?

[Jan Klemkow]

On Wed, Jul 07, 2021 at 08:55:07AM +0800, Patrick wrote:
> What's a good minimal sshd?
> Or should we just run stunnel + telnetd?

Telnet + TLS or rsh + TLS is also a possible solution.  stunnel is not
enough.  If you want to have a serious minimal replacement for ssh, you
will need key-based authentication.  So, in my opinion for such a
project you could combine libtls from Libressl with telnetd.

just me two cents,
Jan

[dev] [Announce] [scroll-0.1] release

[Jan Klemkow]

Hello community,

scroll is now tagged 0.1 as release and available as a tarball.  I want
to thank all people who made patch contributions to make scroll better.

scroll-0.1: https://dl.suckless.org/tools/scroll-0.1.tar.gz

Further information under https://tools.suckless.org/scroll/

bye,
Jan

Re: [dev] [ii] SASL over TOR question

[Jan Klemkow]

On Fri, Jan 15, 2021 at 01:42:43AM -0800, Spenser Truex wrote:
> Has anyone a working setup for ii->sasl->tor?

I use ii with ucspi-patch[1] and ucspi-tools[2] to connect to IRC
servers via Tor and with SSL for certificate-user-authentication.

[1]: https://tools.suckless.org/ii/patches/ucspi/
[2]: https://github.com/younix/ucspi/

-Jan

Re: [dev] tlsrp: a simple TLS reverse proxy

[Jan Klemkow]

Hi Nihal,

On Sun, Jul 05, 2020 at 04:19:13PM -0500, Nihal Jere wrote:
> I wrote a very simple TLS reverse proxy which can be used as a companion
> to quark. Essentially, it just turns quark's HTTP into HTTPS. It depends
> only on libtls (from LibreSSL) and libbsd (for strlcpy).
> 
> You can read more about it here:
> https://nihaljere.xyz/words/tlsrp.html
> 
> and clone it from here:
> git://nihaljere.xyz/tlsrp
> 
> I would appreciate any comments or criticism.

Its a nice project.  I cloned your repository and make some changes.
Look at https://github.com/younix/tlsrp  I tried to make small changes
with explicit comments.  So, you can see, what and why I change things.

I did...

 1. I refactored the Makefile to make it more portable
 2. Add dependencies in your make rules
 3. Increase compiler warnings and fix issues for better code quallity

Additionally someone should...

 4. You need to choose a Licence for you project.  So, others know
under which terms they can use your software.  I would recommend
ISC or MIT licence.
 5. You should change the command parameters.  Choose one character
options for your parameters and use getopt(3) to parse them.

At least, I like your project and hope you could bring it in a final
state.

bye,
Jan

[dev] [ii]: path to apply action command

[Jan Klemkow]

Hi,

this path applies action command support to ii.  It was developed at the
slcon4, but I was to lazy.  So, I sent it now.

Any comments or questions?

Bye,
Jan

>From 1ddd9265ff3601cc07181d3fc79d33296c77adaf Mon Sep 17 00:00:00 2001
From: Jan Klemkow <j.klem...@wemelug.de>
Date: Thu, 7 Sep 2017 22:00:29 +0200
Subject: [PATCH] add support for irc action command

---
 ii.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/ii.c b/ii.c
index 6583792..e2db622 100644
--- a/ii.c
+++ b/ii.c
@@ -505,6 +505,17 @@ proc_channels_input(int ircfd, Channel *c, char *buf)
snprintf(msg, sizeof(msg), "NICK %s\r\n", 
[3]);
}
break;
+   case 'm': /* action */
+   if (buflen >= 3) {
+   snprintf(msg, sizeof(msg), "*%s %s", nick, 
[3]);
+   channel_print(c, msg);
+   snprintf(msg, sizeof(msg),
+"PRIVMSG %s :\01ACTION %s\01\r\n",
+c->name, [3]);
+   ewritestr(ircfd, msg);
+   return;
+   }
+   break;
case 'l': /* leave */
if (c == channelmaster)
return;
@@ -545,6 +556,7 @@ proc_server_cmd(int fd, char *buf)
Channel *c;
const char *channel;
char *argv[TOK_LAST], *cmd = NULL, *p = NULL;
+   char text[IRC_MSG_MAX] = { '\0', '\0' };
unsigned int i;
 
if (!buf || buf[0] == '\0')
@@ -641,8 +653,12 @@ proc_server_cmd(int fd, char *buf)
snprintf(msg, sizeof(msg), "-!- \"%s\")",
argv[TOK_TEXT] ? argv[TOK_TEXT] : "");
} else if (!strcmp("PRIVMSG", argv[TOK_CMD])) {
-   snprintf(msg, sizeof(msg), "<%s> %s", argv[TOK_NICKSRV],
-   argv[TOK_TEXT] ? argv[TOK_TEXT] : "");
+   if (sscanf(argv[TOK_TEXT], "\01ACTION%[^\01]\01", text) == 1)
+   snprintf(msg, sizeof(msg), "*%s %s", argv[TOK_NICKSRV],
+*text ? [1] : "");
+   else
+   snprintf(msg, sizeof(msg), "<%s> %s", argv[TOK_NICKSRV],
+argv[TOK_TEXT] ? argv[TOK_TEXT] : "");
} else {
return; /* can't read this message */
}
-- 
2.14.1

[dev] name for ii-like chatting

[Jan Klemkow]

Hi,

I am programming on front-end and back-end tools for ii for several
years now.  For the back-end I use UCSPI[0] (Unix Client Server Program
Interface).  But there is no name for the front-end of tools like ii[1],
ratox[2], sj[3] or jj[4].  I used the term "ii-like" in my talk at the
slcon3, because ii was the first of its kind.  But, I am unhappy with
this term and looking for a better word or phrase which fits to this
kind of interface.

Do you have any ideas of a name for the ii-like front-end interface?

Thanks,
Jan

[0]: https://cr.yp.to/proto/ucspi.txt
[1]: http://tools.suckless.org/ii/
[2]: http://ratox.2f30.org/
[3]: http://github.com/younix/sj/
[4]: http://23.fi/jj/ 

Re: [dev] MIT/BSD licensed ELF linker?

[Jan Klemkow]

I don't know if it is production ready, but a former the former OpenBSD
developer mickey@ has written an own static linker, which he uses for
his OpenBSD fork AErieBSD.

The AErieBSD-Project is dead, but his linker is at github:
https://github.com/McIkye/tools

bye,
Jan

On Tue, Aug 04, 2015 at 10:42:53PM +0200, Anselm R Garbe wrote:
> Hi there,
> 
> I'm working on a new stali distro (current state will be published
> during the next days) and am looking for a ELF capable linker that
> doesn't suffers from GPL/copyleft licensing issues.
> 
> Background: I need to solve the problem of not offering pre-linked
> binaries that combine GPLed portions with other licensed portions...
> but to come up with a neat solution, I'd like to rely on a free ELF
> linker.
> 
> Suggestions?
> 
> Best regards,
> Anselm


signature.asc
Description: PGP signature

Re: [dev] sj: bug in receiving presence

[Jan Klemkow]

Hi Greg,

presenced was the last daemon I wrote just before the slcon2.  Its just
a short hack, that I didn't check to run correctly in real usage :-)

Thanks for the diffs.  I'll have a look at them tonight.  Because I am
busy now.  But it looks good, beside of a few stylistic things.

bye,
Jan

On Tue, Dec 08, 2015 at 03:16:24PM -0500, Greg Reagle wrote:
> I fixed the problem.  I want to clean up and test my modification some more
> before I submit it.

Re: [dev] sj: bug in receiving presence

[Jan Klemkow]

I committed your diff for presenced with a following clean up.  But
maybe, I will change the presenced semantic a bit.

But for the moment I fixes the daemon in a very good way.
Thanks for your help!

bye,
Jan

On Tue, Dec 08, 2015 at 01:57:26PM -0500, Greg Reagle wrote:
> In this message, I point out the error and state the correct way of
> receiving presence.  FRIGN, please don't call me a help vampire. :>  I do
> plan to write the patch, but it might take me a little while.
> 
> Re: https://github.com/younix/sj
> 
> in presenced.c in recv_presence(), lines 254-255
> status = mxmlFindElement(node, tree, "status", NULL, NULL,
> MXML_DESCEND_FIRST);
> but this always return NULL when I use sj, even for buddies who are online.
> This is because their presence message does not have a status element.  None
> of the presence messages that I see via sj, either online or offline, have a
> status element.  The standard states that a status element is optional [1].
> The standard states that the way to indicate that a buddy is online is the
> absence of a 'type' attribute. [2].
> 
> [1] http://xmpp.org/rfcs/rfc3921.html  2.2.2.2.  Status
> [2] http://xmpp.org/rfcs/rfc3921.html  2.2.1.  Types of Presence

Re: [dev] debugging sj

[Jan Klemkow]

On Fri, Dec 04, 2015 at 11:21:17AM -0500, Greg Reagle wrote:
> On 12/04/2015 12:57 AM, Jan Klemkow wrote:
> >I wrote ucspi-tee[1] to do this job for me.  But I think there is a
> >similar tool of djb's tool chain, that does it, too.
> 
> Okay yes I can compile and run your program ucspi-tee.  But how exactly do I
> use it?  This is how I (successfully) use sj now:
>   env TLSC_NO_VERIFICATION=1 tcpclient "$SJ_SERVER" 5223 tlsc sj
> 
> Where do I put ucspi-tee in that command?  Sorry I don't understand better.

No problem.  You should plug between tlsc and sj, so it is able to
intercept all input and output traffic of sj before the encryption.

env TLSC_NO_VERIFICATION=1 tcpclient "$SJ_SERVER" 5223 tlsc ucspi-tee sj

bye,
Jan

Re: [dev] sj: explicit tlsc doesn't work

[Jan Klemkow]

Hi Greg,

Sorry for the late answer, but I was busy the last days.

On Tue, Dec 01, 2015 at 10:37:44AM -0500, Greg Reagle wrote:
> Thanks to the recent updates to sj[1] and ucspi-tools[2], sj is now easier
> to build.
> 
> The man page for sj has this
> 
> EXAMPLES
>  tcpclient example.org 5223 tlsc sj -u user -s example.org

You are right, I forgot to extend that part of the manpage.  Its now
updated.
 
> but that doesn't work for me.  I have to omit tlsc.  It seems to be called
> automatically.  Am I doing something wrong or does the man page need to be
> corrected?  Here is how I run sj:

Yes, now sj starts tlsc automatically after the STARTTLS negotiation.
You should not omit tlsc.  The traffic will be unencrypted if you do so.

>  tcpclient "$SJ_SERVER" xmpp-client sj
> 
> with the following env vars:
> 
> ~/a/sj$ env|grep SJ
> SJ_DIR=/home/greagle/sj
> SJ_RESOURCE=sj
> SJ_SERVER=jabber.org
> SJ_USER=taiga
> 
> and TLSC_NO_VERIFICATION=1
> 
> Note that "xmpp-client" is looked up in /etc/services and maps to 5222.
> 
> [1] https://github.com/younix/sj
> [2] https://github.com/younix/ucspi

Re: [dev] sj: explicit tlsc doesn't work

[Jan Klemkow]

On Thu, Dec 03, 2015 at 03:23:16PM -0500, Matthew of Boswell wrote:
> On Tue, 1 Dec 2015 10:37:44 -0500
> Greg Reagle  wrote:
> 
> > but that doesn't work for me.  I have to omit tlsc.  It seems to be 
> > called automatically.  Am I doing something wrong or does the man page 
> > need to be corrected?
> 
> I think it's a combination. I got it working around the same time you
> did but forgot to post that it worked. I think Jan wants to find a
> cleaner solution, but for now sj calls tlsc.

This solution it the final one, I think.  sj is calling tlsc with its
own arguments.  So that tlsc starts sj in the same way as before.  This
looks like the right way to keep all tools clean and simple.

The aim is, that every tool just handles its own protocol and not parts
of other protocols and programs.  One program for one protocol.

> Having sj call tlsc doesn't really bother me... I guess because I can't
> think of a better way to start in xmpp, negotiate tls, then continue in
> encrypted xmpp.
> 
> -- 
> Matt Boswell

Re: [dev] debugging sj

[Jan Klemkow]

On Tue, Dec 01, 2015 at 11:35:46AM -0500, Greg Reagle wrote:
> On 12/01/2015 10:55 AM, Greg Reagle wrote:
> >I don't experience any bugs in sj, but I would like to see the raw XML
> >messages that are sent back and forth via sj, messaged, iqd, and
> >presenced, in order to be able to understand better.
> >
> >These programs write to "in" files (named pipes).  So what is the best
> >(easiest, most convenient) way to get this info?
> >
> >I could add debug-guarded printf statements all over the code.  What
> >about using the tee command?  That seems like that might work
> >conceptually, but I don't have the expertise to know how to do this.
> 
> I discovered strace, which does the job.

I wrote ucspi-tee[1] to do this job for me.  But I think there is a
similar tool of djb's tool chain, that does it, too.

If you want to see all XMPP traffic, you should try to avoid the
STARTTLS negotiation of sj itself.  Try to connect directly to a TLS
port like 5223 of jabber.ccc.de.

If you just want to see the traffic thats happend after the STARTTLS
negotiation, you could also extend the argument list that sj uses to
start tlsc.  Just insert "ucspi-tee" as the second argument.  That
should work.  (and don't forget to extend the argument list length)

[1]: https://github.com/younix/ucspi/blob/master/ucspi-tee.c

Re: [dev] sj

[Jan Klemkow]

On Mon, Nov 23, 2015 at 10:52:24AM -0500, Greg Reagle wrote:
> I did build thusly:
> 
> installed version 1:0.88-3 of ucspi-tcp:
> http://packages.ubuntu.com/trusty/ucspi-tcp
> 
> built and installed https://github.com/libressl-portable/portable
> 
> cloned https://github.com/younix/ucspi, then commented out ERR_get_error and
> ERR_error_string, built, installed
> 
> cloned https://github.com/younix/sj, then
> changed explicit_bzero to bzero, built, installed
> 
> Here is what happens for me:
> ~/a/sj$ env| grep SJ
> SJ_DIR=/home/greagle/sj
> SJ_SERVER=jabber.org
> SJ_USER=taiga
> ~/a/sj$ tcpclient jabber.org 5222 sj
> tlsc: tls_error: ssl verify setup failure

The tls certificate verification failed.  Turn it off with the following
environment variable:

export TLSC_NO_VERIFICATION=1

bye,
Jan 


pgp7j7FTy3xlR.pgp
Description: PGP signature

Re: [dev] sj: ucspi

[Jan Klemkow]

On Sun, Nov 22, 2015 at 02:20:51AM -0500, Matthew of Boswell wrote:
> On Sun, 22 Nov 2015 03:21:12 +0100
> Jan Klemkow <j.klem...@wemelug.de> wrote:
> > I implemented STARTTLS.  But there is a hard coded hack, that there is
> > no certificate verification at the moment.  I have to find a way to give
> > options through sj to tlsc. But, I think that this is a good way to
> > handle this problem.
> > Could you test the new state with your use cases?
> 
> Sure. Here's what I did:
> 
> 1. replace openssl with the archlinux experimental libressl package.
> 
> 2. build tlsc. I have libressl and libbsd installed. Looks like I don't
> have these two functions:
> ERR_get_error
> ERR_error_string
> 
> So, I commented out the error reporting code and proceeded =)
> 
> 3. build sj. Oops, explicit_bzero doesn't exist... I guess it's an
> openbsd/freebsd thing? I replaced the calls with bzero (insecure; oh
> well).

I thought it is part of libbsd.  I'll turn it into an optional feature.

> 4. Run program:
> % env | grep SJ
> SJ_USER=gnuman
> SJ_DIR=/home/matt/.xmpp
> SJ_SERVER=dukgo.com
> % tcpclient dukgo.com 5222 ./sj
> tlsc: tls_error: name `ec2-23-21-227-59.compute-1.amazonaws.com' not present 
> in server certificate
> 
> Is it trying to verify the certificate? I don't know how to override
> the check. I tend to treat xmpp ssl certificates like ssh host keys -
> store them and only worry if there's a mismatch.

Yes. It doesn't check the cert chain, but the hostname.  It looks like
that the hostname doesn't match.  You can turn it off with the -H option
of tlsc.  Certificate fingerprint check should be implemented in tlsc to
do this.  Its already on my TODO list ;-)

> Are you developing this from openbsd? explicit_bzero appears to be
> fairly new, and FreeBSD only got it as of 11.0.

Yes, I'm work with OpenBSD.

> It might make sense to do tls from within sj itself. Chaining it
> through tlsc seems to add complexity, not reduce it. Also, I think
> proper XMPP requires a few DNS lookups on SRV records to even know which
> server to initiate TCP with.

It is part of the core design to split up TLS handling and XMPP handling
into separate tools.  I think, configuring tlsc with environment
variable beside of command line options is the proper way to handle this
problem.  I'll try make some changes in tlsc.

The check of the SRV records is missing feature, too.  I don't have a
plan how to deal with it at the moment.

Thanks,
Jan


pgpaqRc9rPB5x.pgp
Description: PGP signature

Re: [dev] sj: ucspi

[Jan Klemkow]

Hey,

I implemented STARTTLS.  But there is a hard coded hack, that there is
no certificate verification at the moment.  I have to find a way to give
options through sj to tlsc. But, I think that this is a good way to
handle this problem.

After STARTTLS negotiation sj starts tlsc with its own arguments behind
the tlsc ones.  So tlsc does the tls handshake and starts sj as it was
stated before.

Could you test the new state with your use cases?

Thanks for reporting,
Jan

On Fri, Nov 20, 2015 at 10:28:08AM +0100, Jan Klemkow wrote:
> Hi,
> 
> Thanks for testing my jabber client and sorry for its inconvenience.
> 
> yes, STARTTLS is not implemented at the moment.  I use jabber.ccc.de for
> testing, cause they use the Port 5223 for TLS which is not recommend.  I
> will implement STARTSSL in the near future, stay tuned.
> 
> sslc(1) is the legacy version that just needed the OpenSSL library.  But
> it doesn't do any cert checks.  tlsc(1) is the recommended version which
> uses LibTLS from LibreSSL.  But have a look at the Version number, I had
> made pachtes for LibreSSL a few month ago which are nessasary for
> tlsc(1).
> 
> Greg: I saw you patch at hackers@, I will have a look at it at this
> weekend.  Thanks!
> 
> bye,
> Jan
> 
> On Thu, Nov 19, 2015 at 07:02:02PM -0500, Matthew of Boswell wrote:
> > On Thu, 19 Nov 2015 15:14:06 -0500
> > Greg Reagle <greg.rea...@umbc.edu> wrote:
> > 
> > > On 11/19/2015 03:11 PM, Matthew of Boswell wrote:
> > > > Note, however, that it did not work with sj. I think the reason is that
> > > > xmpp port 5222 is a STARTTLS port, not a straight SSL port.  
> > > 
> > > Maybe that's why the example in the man page of sj uses port 5223, 
> > > expecting that to be a straight SSL port.
> > > 
> > 
> > Ah, the man page. I forgot to check that... I guess I assumed that if
> > README.md was out of date, the manpage would be as well. Let me know if
> > you can get it working. My xmpp server (dukgo.com) doesn't have port
> > 5223 open.
> > 
> > I guess tlsc wouldn't be able to work on 5222, since STARTTLS is an
> > application-level negotiation. Maybe best to do the tls inside sj?
> > 
> > -- 
> > Matt Boswell
> > 




pgpxCba1rb8bN.pgp
Description: PGP signature

Re: [dev] sj: ucspi

[Jan Klemkow]

Hi,

Thanks for testing my jabber client and sorry for its inconvenience.

yes, STARTTLS is not implemented at the moment.  I use jabber.ccc.de for
testing, cause they use the Port 5223 for TLS which is not recommend.  I
will implement STARTSSL in the near future, stay tuned.

sslc(1) is the legacy version that just needed the OpenSSL library.  But
it doesn't do any cert checks.  tlsc(1) is the recommended version which
uses LibTLS from LibreSSL.  But have a look at the Version number, I had
made pachtes for LibreSSL a few month ago which are nessasary for
tlsc(1).

Greg: I saw you patch at hackers@, I will have a look at it at this
weekend.  Thanks!

bye,
Jan

On Thu, Nov 19, 2015 at 07:02:02PM -0500, Matthew of Boswell wrote:
> On Thu, 19 Nov 2015 15:14:06 -0500
> Greg Reagle  wrote:
> 
> > On 11/19/2015 03:11 PM, Matthew of Boswell wrote:
> > > Note, however, that it did not work with sj. I think the reason is that
> > > xmpp port 5222 is a STARTTLS port, not a straight SSL port.  
> > 
> > Maybe that's why the example in the man page of sj uses port 5223, 
> > expecting that to be a straight SSL port.
> > 
> 
> Ah, the man page. I forgot to check that... I guess I assumed that if
> README.md was out of date, the manpage would be as well. Let me know if
> you can get it working. My xmpp server (dukgo.com) doesn't have port
> 5223 open.
> 
> I guess tlsc wouldn't be able to work on 5222, since STARTTLS is an
> application-level negotiation. Maybe best to do the tls inside sj?
> 
> -- 
> Matt Boswell
> 


pgpa7KRXEsydR.pgp
Description: PGP signature

Re: [dev] [slcon2] Videos are now online!

[Jan Klemkow]

Thanks for that advice.  Done!

On Thu, Nov 19, 2015 at 01:13:36PM +0800, Pickfire wrote:
> Hi, I think it is better to add http://klemkow.net/sj.html link to the
> github repository.


pgp9CCc3W083L.pgp
Description: PGP signature

Re: [dev] [slcon2] Videos are now online!

[Jan Klemkow]

And there is also a short paper for this talk, which should be linked on
the conference website.

http://klemkow.net/sj.pdf

FRIGN: Where is the right place to upload this pdf on the suckless
server?

thanks,
Jan

On Wed, Nov 18, 2015 at 04:55:27PM +0100, FRIGN wrote:
> On Wed, 18 Nov 2015 10:52:19 -0500
> Greg Reagle <greg.rea...@umbc.edu> wrote:
> 
> > Great, thanks.  Is there any code for "Simple Jabber - Divide And Conquer 
> > XMPP, Jan Klemkow"?
> 
> http://klemkow.net/sj.html
> 
> code: https://github.com/younix/sj
> 
> -- 
> FRIGN <d...@frign.de>


pgpm1X_KrD5gi.pgp
Description: PGP signature

[dev] suckless assembly at 32C3

[Jan Klemkow]

Hi,

I would like to organize an assembly for the suckless community at the
32C3.  If you want to attend this to this assembly, reply on this mail.
Unlike the last year, I won't organize an empty assembly.  I will orga-
nize one, if at least five people (including myself) promise to attend.
In my opinion we should use this event as a possibility to hack on our
software, like a hackathon.

bye,
Jan