Re: [dev] wego: a weather app for the terminal written in go

2015-01-15 Thread Nick
Quoth Markus Teich:
> Nick wrote:
> > It uses Weather Underground, which means it has hourly info, and lots of 
> > other
> > forecast stuff that the script is just ignoring for now. It also loads the
> > json with the weather data without needing an API key, because that shit is
> > for chumps.
> 
> For me, SSL support was more important than not having to use an API key. I 
> did
> not find a service providing both.

Oh, I didn't notice it had SSL support, that's nice. You could look 
into grabbing the data however the web frontend does (in my script 
that involves grabbing a randomly generated key from an HTML page to 
use in the json request). Though if it does things server side that 
would mean you might just have to parse HTML, which is never ideal.



Re: [dev] wego: a weather app for the terminal written in go

2015-01-15 Thread Markus Teich
Markus Wichmann wrote:
> When I tried to run it, it would just print "Malformed response". I added a
> line to dump the URL to stderr before that and tried to get it with wget, and
> the response I get is 403 Forbidden. What am I doing wrong?

Did you read the setup section[0] in the README? You have to get an API key
first (it's free, you only need a github account) and put it into your ~/.wegorc

--Markus

0: http://www.worldweatheronline.com/api/docs/local-city-town-weather-api.aspx



Re: [dev] security issue running surf from home folder

2015-01-15 Thread Carlos Torres
Hello,

On Wed, Jan 7, 2015 at 3:29 PM, Christoph Lohmann <2...@r-36.net> wrote:
> Theses patches have been discussed on IRC. The optimal solution has been
> to make the default DOWNLOAD macro to ask for a string. If the string is
> empty,  pass  ‐O  to  curl,  if  it’s non‐empty add ‐‐create‐dirs and ‐o
> $string to curl.
>
> Any comments on this?
>

For a while now, i've been maintaining a patch in my queue that cd's to
a downloads destination dir in the DOWNLOAD macro.  it would be nice to
have what you mentioned above. -D/-d hasn't been taken maybe that could
enabledownloadprompt?

--Carlos



[dev] [ii] Patch to use ii with UCSPI backend

2015-01-15 Thread younix
Hi,

this diff changes the network connection of ii to the UCSPI[1] protocol.
This makes ii much more flexible.  With the UCSPI protocol you could use
features like IPv6[2], SOCKSv5[3] or even TLS[3].  This diff extracts
the socket handling infrastructure to an external program like
tcpclient.  So it shrinks the codebase and complexity.

What is your opinion about this diff?  At least it would be great to put
this patch at the ii suckless webpage.  So I could made an OpenBSD port
(flavor) of it.

You can uses ii in the following manner:

1. Direct plain IRC connection

   tcpclient irc.freenode.net 6667 ii

2. TLS encrypted connection

   tcpclient irc.freenode.net 6697 tlsc ii

3. TLS connection in combination with a SOCKS proxy

   tcpclient 127.0.0.1 1080 socks irc.freenode.net 6697 tlsc ii

 [1]: http://cr.yp.to/proto/ucspi.txt
 [2]: http://www.fefe.de/ucspi/
 [3]: https://github.com/younix/ucspi

bye,
younix

commit 6109304028cba410862dfe2e827f7941ba5dfa2f
Author: Jan Klemkow 
Date:   Mon Jan 12 18:05:42 2015 +0100

change network access through ucspi

diff --git a/ii.c b/ii.c
index d93266c..fad523c 100644
--- a/ii.c
+++ b/ii.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 
+#define UCSPI_READ 7
+#define UCSPI_WRITE 6
+
 #ifndef PIPE_BUF /* FreeBSD don't know PIPE_BUF */
 #define PIPE_BUF 4096
 #endif
@@ -33,10 +36,9 @@ struct Channel {
Channel *next;
 };
 
-static int irc;
 static time_t last_response;
 static Channel *channels = NULL;
-static char *host = "irc.freenode.net";
+static char *host = NULL;
 static char nick[32];  /* might change while running */
 static char path[_POSIX_PATH_MAX];
 static char message[PIPE_BUF]; /* message buf used for communication */
@@ -148,31 +150,7 @@ static void login(char *key, char *fullname) {
nick, nick, host, fullname ? fullname : nick);
else snprintf(message, PIPE_BUF, "NICK %s\r\nUSER %s localhost %s 
:%s\r\n",
nick, nick, host, fullname ? fullname : nick);
-   write(irc, message, strlen(message));   /* login */
-}
-
-static int tcpopen(unsigned short port) {
-   int fd;
-   struct sockaddr_in sin;
-   struct hostent *hp = gethostbyname(host);
-
-   memset(&sin, 0, sizeof(struct sockaddr_in));
-   if(!hp) {
-   perror("ii: cannot retrieve host information");
-   exit(EXIT_FAILURE);
-   }
-   sin.sin_family = AF_INET;
-   memcpy(&sin.sin_addr, hp->h_addr, hp->h_length);
-   sin.sin_port = htons(port);
-   if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
-   perror("ii: cannot create socket");
-   exit(EXIT_FAILURE);
-   }
-   if(connect(fd, (const struct sockaddr *) &sin, sizeof(sin)) < 0) {
-   perror("ii: cannot connect to host");
-   exit(EXIT_FAILURE);
-   }
-   return fd;
+   write(UCSPI_WRITE, message, strlen(message));   /* login */
 }
 
 static size_t tokenize(char **result, size_t reslen, char *str, char delim) {
@@ -219,7 +197,7 @@ static void proc_channels_privmsg(char *channel, char *buf) 
{
snprintf(message, PIPE_BUF, "<%s> %s", nick, buf);
print_out(channel, message);
snprintf(message, PIPE_BUF, "PRIVMSG %s :%s\r\n", channel, buf);
-   write(irc, message, strlen(message));
+   write(UCSPI_WRITE, message, strlen(message));
 }
 
 static void proc_channels_input(Channel *c, char *buf) {
@@ -273,7 +251,7 @@ static void proc_channels_input(Channel *c, char *buf) {
else
snprintf(message, PIPE_BUF,
"PART %s :ii - 500 SLOC are too 
much\r\n", c->name);
-   write(irc, message, strlen(message));
+   write(UCSPI_WRITE, message, strlen(message));
close(c->fd);
/*create_filepath(infile, sizeof(infile), c->name, 
"in");
unlink(infile); */
@@ -288,7 +266,7 @@ static void proc_channels_input(Channel *c, char *buf) {
snprintf(message, PIPE_BUF, "%s\r\n", &buf[1]);
 
if (message[0] != '\0')
-   write(irc, message, strlen(message));
+   write(UCSPI_WRITE, message, strlen(message));
 }
 
 static void proc_server_cmd(char *buf) {
@@ -339,7 +317,7 @@ static void proc_server_cmd(char *buf) {
return;
} else if(!strncmp("PING", argv[TOK_CMD], 5)) {
snprintf(message, PIPE_BUF, "PONG %s\r\n", argv[TOK_TEXT]);
-   write(irc, message, strlen(message));
+   write(UCSPI_WRITE, message, strlen(message));
return;
} else if(!argv[TOK_NICKSRV] || !argv[TOK_USER]) {  /* server 
command */
snprintf(message, PIPE_BUF, "%s%s", argv[TOK_ARG] ? 
argv[TOK_ARG] : "", argv[TOK_TEXT] ? argv[TOK_TEXT] : "");
@@ -402,7 +380,7 @@ static void handle_channels_input(Channe

Re: [dev] [ii] Patch to use ii with UCSPI backend

2015-01-15 Thread Markus Teich
younix wrote:
> What is your opinion about this diff?  At least it would be great to put this
> patch at the ii suckless webpage.  So I could made an OpenBSD port (flavor) of
> it.

As I've already told you on 31c3 I think the separation in socket/tls/protocol
layers is very good and can be reused for other protocols (your secret project,
which you didn't announce yet ;)) easily. If it is not accepted upstream,
you can push your patch to the website[0] on your own.

Arguments against adapting it upstream would be the additional dependencies.
Since I like to spread ii in situations with no internet access and people in
desperate need of an IRC client to join the local IRC server and don't want to
include other dependencies, a new branch might be used. What do you think?

--Markus

0: http://suckless.org/wiki