Re: [dev] dwm: force fullscreen to tile
See this thread http://lists.suckless.org/dev/1402/20190.html about that. I'm not sure if it still applies to current version. On 21 November 2015 at 00:46, Draco Metallium(Rodrigo S. Cañibano) wrote: > I'm loving this WM! > > I just made a quick hack to unfloat fullscreen windows. > > On 20 November 2015 at 16:23, Draco Metallium(Rodrigo S. Cañibano) > wrote: >> Thanks, I'll try that. >> >> But if you come to a more general solution(so it can be apply to other >> programs), I would be please to hear it! >> >> On 20 November 2015 at 13:51, Staven wrote: >>> On Fri, Nov 20, 2015 at 10:47:54AM -0300, Draco Metallium(Rodrigo S. >>> Cañibano) wrote: Good day. I was wondering, is there some way to force fullscreen apps to a tile? For example, in i3wm I could put a youtube video in full screen, then turn i3wm full screen off, and the video would continue in 'full screen' but inside a tile. Can it be done? Thanks! And sorry for the wroken English. >>> >>> I don't know about forcing fullscreen windows to tile, but if you just >>> want to watch YT videos, you could try mpv (https://mpv.io/). >>> It supports playing YouTube (and other video sites) via youtube-dl >>> and it's not too terrible from the suckless perspective, in my opinion. >>> >>> -- __ Raphaël Proust
Re: [dev] [st] Reporting a Segmentation fault
On Fri, Nov 20, 2015 at 9:00 PM, Greg Reagle wrote:
> That's right--buf is accessed without bounds checked. The problem is in
> ttyread() in the while loop, buf gets overflowed, i.e. ptr - buf exceeds
> BUFSIZ (8192). Haven't figured out how to remedy the problem (yet).
>
>
What makes you think this is an overflow? The leading one-bits in clen
to me clearly hint that this happens through forming a negative
buflen, hence my use of the word underflow.
Apart from that, I still get segfaults with even this overly
pessimistic check in the code:
while ((charsize = utf8decode(ptr, &unicodep, buflen)) &&
buflen - charsize > 0 && ptr - buf + charsize < BUFSIZ - 4) {
tputc(unicodep);
ptr += charsize;
buflen -= charsize;
}
The underflow on my gdb test being in the minus hundred thousands even
makes it look as if it was something else like the read() call that
overflowed. Eww.
cheers!
mar77i
Re: [dev] Re: [sbase] cal doesn't highlight current day
On Fri, Nov 20, 2015 at 06:53:53PM +, Connor Lane Smith wrote: > On 20 November 2015 at 18:40, Connor Lane Smith wrote: > > I've attached a patch. It's not too bad, although it does have ugly > > escape codes. But I don't actually mind either way. > > Slightly uglier bugfix. I've applied the patch, thanks!
Re: [dev] [st] Reporting a Segmentation fault
On Sat, Nov 21, 2015 at 11:08:08AM +0100, Martti Kühne wrote: > What makes you think this is an overflow? Because the segmentation fault occurs when ptr goes past the end of buf.
Re: [dev] [st] Reporting a Segmentation fault
On Sat, Nov 21, 2015 at 06:57:30AM -0500, Greg Reagle wrote: > On Sat, Nov 21, 2015 at 11:08:08AM +0100, Martti Kühne wrote: > > What makes you think this is an overflow? > > Because the segmentation fault occurs when ptr goes past the end of buf. But you're right that buflen becomes a negative number sometimes too. This function was written with no bounds checking on either buflen or ptr. I've been trying to wrap my head around how to do it properly.
[dev] Applying patches to dwm
Hello, I don't seem to be able to apply any patch which is present on http://dwm.suckless.org/dwmstatus, specifically here's what I tried: - I cloned the git repo of dwm - downloaded the statuscolours patch - did "git apply dwm-6.1-statuscolors.diff" and the output is: error: patch failed: drw.c:202 error: drw.c: patch does not apply error: patch failed: drw.h:67 error: drw.h: patch does not apply error: patch failed: dwm.c:261 error: dwm.c: patch does not apply This happens with many patches I've tried to apply to my dwm. I tried with dwm tarball as well, same results. Any help is appreciated, thanks! Antonio.
Re: [dev] [sent] 0.1 release
On 11/20, Claudio wrote: > I've implemented a web-based "port" of sent called wsent. I agree > to not use the web for anything so I decided to abandon the project > after reading the Quenting Rameau post where he suggests a slide to > image conversion. Though, since I've put some effort on writing wsent > (which is in still in a early stage) I though someone may be > interested. I created the repository[0] again. I wouldn't bother with Quenting Rameau's idea of converting the slides into images, some reasons against it: - How do you decide which resolution the images should be rendered? (too small to read? too blurry in fullscreen? too big?) - How do you copy text from it? - Does every image reader support reading images inorder? It's true that the web sucks, however I'd consider presenting text and some images totally OK for use on the web platform: + You're publishing this; it's a good idea if a lot of people can view the content. + The text can be copied - We're dealing with web browsers; there will be issues. Ofcourse you could just release the .txt file however I can see some non-technical people prefer to have the slides as you presented them, the web platform will fit well for this. If I publish a sent presentation it will be in the original .txt and web format. Alternatively I've seen LaTeX Beamer presentations released in a "paper" format where the slides are reformatted so they fit into the paper like regular text and only some small "ticks" which works as indicators of where slide bounderies are[0]. Another thing to think about; what about printing the slides? Maybe Takahashi method slides don't fit well on paper slides? Note; that I'm merely presenting my opinions/ideas, there may be issues with them. [0]: http://ftp.acc.umu.se/mirror/CTAN/macros/latex/contrib/beamer/examples/beamerexample-lecture-print-version.pdf
Re: [dev] Applying patches to dwm
On Sat, Nov 21, 2015 at 01:48:21PM +0100, Antonio Cardace wrote: I don't seem to be able to apply any patch which is present on http://dwm.suckless.org/dwmstatus, specifically here's what I tried: - I cloned the git repo of dwm - downloaded the statuscolours patch - did "git apply dwm-6.1-statuscolors.diff" and the output is: error: patch failed: drw.c:202 error: drw.c: patch does not apply error: patch failed: drw.h:67 error: drw.h: patch does not apply error: patch failed: dwm.c:261 error: dwm.c: patch does not apply This happens with many patches I've tried to apply to my dwm. I guess you are a newbie. Patches doesn't apply normally because that: 1. It is outdated, nobody has update it. You are welcome to update it. 2. You had applied another patch beforehand that overlap the patches. To overcome these problem, try: 1. `git apply patch -3v` 2. Edit the file and find `==`, fix those lines, eg. - Remove < and >, just fix it. 3. `git add those files` 4. That patch is updated and you are welcome to add it to the wiki. Good luck and have a nice day! -- _ < Do what you like, like what you do. > - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || ||
Re: [dev] [sent] 0.1 release
Heyho, Claudio wrote: > I've implemented a web-based "port" of sent called wsent. I agree to not > use the web for anything so I decided to abandon the project after reading > the Quenting Rameau post where he suggests a slide to image conversion. > Though, since I've put some effort on writing wsent (which is in still in a > early stage) I though someone may be interested. I created the repository > again. ACE wrote: > It's true that the web sucks, however I'd consider presenting text and > some images totally OK for use on the web platform: > + You're publishing this; it's a good idea if a lot of people can view > the content. > + The text can be copied > - We're dealing with web browsers; there will be issues. > > Ofcourse you could just release the .txt file however I can see some > non-technical people prefer to have the slides as you presented them, the web > platform will fit well for this. > > If I publish a sent presentation it will be in the original .txt and web > format. > > Alternatively I've seen LaTeX Beamer presentations released in a "paper" > format where the slides are reformatted so they fit into the paper like > regular text and only some small "ticks" which works as indicators of where > slide bounderies are. > > Another thing to think about; what about printing the slides? I am willing to accept a patch of a sed/awk shell script converting a slide file to static html (just use and blocks) page or a .tex input file for a latex document (no beamer presentation, you already have sent for presenting) to be printed. > Maybe Takahashi method slides don't fit well on paper slides? The takahashi and monte methods are not meant for sharing in any other way than the real presentation or a recording of it. --Markus
Re: [dev] dwm: force fullscreen to tile
On Fri, Nov 20, 2015 at 2:47 PM, Draco Metallium(Rodrigo S. Cañibano) wrote: > Good day. > > I was wondering, is there some way to force fullscreen apps to a tile? > > For example, in i3wm I could put a youtube video in full screen, then > turn i3wm full screen off, and the video would continue in 'full > screen' but inside a tile. > > Can it be done? > > Thanks! And sorry for the wroken English. > I like to use a separate fullscreen layout for such things. It is based on the default monocle layout but it toggles the borders around clients and toggles the statusbar. Example (NOTE: code is pre-dwm 6.1): togglefullscreen function to toggle layout and hide drawbar: http://git.codemadness.nl/dwm/tree/dwm.c?h=hiltjo#n1783 fullscreen layout based on monocle: http://git.codemadness.nl/dwm/tree/dwm.c?h=hiltjo#n1226 Kind regards, Hiltjo
[dev] [surf] background window color
Heyho,
a little annoyance, that bugged me for quite a while is that you get a short
white "flash" when changing between different tabbed clients running surf. This
is mostly only visible when both websites have a dark background. I tested it
and I can "fix" it for these cases with the following lines:
GdkColor bla = {0,0,0,0};
gdk_window_set_background(GTK_WIDGET(c->win)->window, &bla);
This effectively sets the XWindows background to black. Now for bright websites
its obviously counterproductive, so my plan was to set the XWindow background
color to the same color used for the tag of the website displayed.
I tried two methods to get this color from webkit, but both failed (returning an
empty string). If you know, how to extract this value from webkit, please let me
know. It should of course also work with custom stylesheets, so basically it
should return the "background-color" value of the "computed" style of the
tag from the inspector.
Here are the two approaches I tried (I put them into the keypress function to
test it on demand during or after pageload has finished):
WebKitDOMDocument *doc;
WebKitDOMElement *body;
WebKitDOMCSSStyleDeclaration *stil;
gchar *color;
if ((doc = webkit_web_view_get_dom_document(c->view))
&& (body = webkit_dom_document_query_selector(doc, "body", NULL))
&& (stil = webkit_dom_element_get_style(body))
&& (color = webkit_dom_css_style_declaration_get_property_value(stil,
"background-color")))
puts(color);
WebKitDOMDocument *doc;
WebKitDOMHTMLBodyElement *body;
WebKitDOMCSSStyleDeclaration *stil;
gchar *color;
if ((doc = webkit_web_view_get_dom_document(c->view))
&& (body = (WebKitDOMHTMLBodyElement*)webkit_dom_document_get_body(doc))
&& (color = webkit_dom_html_body_element_get_background(body)))
puts(color);
--Markus
Re: [dev] Applying patches to dwm
On Sat, 21 Nov 2015 21:48:33 +0800 Pickfire wrote: > On Sat, Nov 21, 2015 at 01:48:21PM +0100, Antonio Cardace wrote: > >I don't seem to be able to apply any patch which is present on > >http://dwm.suckless.org/dwmstatus, specifically here's what I tried: > > [snip] > >This happens with many patches I've tried to apply to my dwm. > > [snip] > Good luck and have a nice day! Note that the dwm 6.1 was just released. The tarball should match git at this point in time. Many of the patches apply to 6.0, so you'll have to tweak them a bit to get them to work. Some of them even say that they're for 6.1 but really apply to a git version of dwm somewhere between 6.0 and 6.1. I just tweaked centeredmaster and push_no_master yesterday and plan to commit them to the wiki soon. I also happen to know that better-borders and systray apply cleanly to 6.1 and git right now, so you could start with those if you're new to hacking dwm. -- Matt Boswell
Re: [dev] Patch naming on the wiki [corrected list]
Regarding updating patches to 6.1... Should I list the fixed files with the version and the abbreviated commit? For example, some patches are listed as 6.1 but really are some git commit between 6.0 and 6.1: dwm-6.1-centeredmaster.diff So I was wondering if I should make the filename more explicit, so we can tell which patches have been updated. 5ed9c48 is the official tagged commit for dwm-6.1: dwm-6.1-5ed9c48-centeredmaster.diff So on the wiki, it would look like this: dwm-6.1-5ed9c48-centeredmaster.diff (2015-11-21) This would make it a bit easier to see which patches are up to date. Or should I just replace the "6.1"-named patches with correct ones with the same name? Not picking on centeredmaster specifically, it just happens to be one of the patches I fixed and applied to my local repo yesterday. I'll put it on the wiki once I know how to name it. David Phillips wrote: > This would solve my above problem, but introduce one of not having the > date as readily available once the patch and wiki are separated. For > example, I accumulate various versions of patches locally, and knowing > which ones I can remove will get interesting/slow with only refs. For this, I tend to just "ls -l" the patch directory on my hard drive to see the date that I downloaded it. Usually that's enough to see how old it is. If the patch didn't apply cleanly, the modified date would show when I fixed it =). -- Matt Boswell
Re: [dev] Applying patches to dwm
On Sat, 21 Nov 2015 15:35:26 -0500 Matthew of Boswell wrote: > Some of them even say > that they're for 6.1 but really apply to a git version of dwm somewhere > between 6.0 and 6.1. If anybody marks his patches for 6.1 when they're just git-heads, he'll be picked up by the suckless bus for a mental treatment. If you want to test your patches against certain versions in your git-repo, just do a "git checkout 6.1" for example to check out version 6.1 and make your changes. Then do a "git diff > tool-6.1-patch.diff" and upload it. For git-patches, do the same but against master. Cheers FRIGN -- FRIGN
Re: [dev] Patch naming on the wiki [corrected list]
On Sat, 21 Nov 2015 15:43:56 -0500 Matthew of Boswell wrote: Hey Matthew, > Regarding updating patches to 6.1... Should I list the fixed files with > the version and the abbreviated commit? For example, some patches are > listed as 6.1 but really are some git commit between 6.0 and 6.1: These patches have been listed wrong and should be removed. We don't maintain old patches. What I'd do is copy the "real" 6.1-patch and call it dwm-git-20151121-centeredmaster.diff and be done with it. If the git-head moves along and it breaks in the future, people will know which patch to change. > So I was wondering if I should make the filename more explicit, so we > can tell which patches have been updated. 5ed9c48 is the official > tagged commit for dwm-6.1: > This would make it a bit easier to see which patches are up to date. No, this just complicates shit. Just use the dates and only use versions for patches which apply against the given tag. > Not picking on centeredmaster specifically, it just happens to be one > of the patches I fixed and applied to my local repo yesterday. I'll put > it on the wiki once I know how to name it. The patch-situation is pretty diffuse atm. Look at the st-patches section[0], which I've already taken care of. > For this, I tend to just "ls -l" the patch directory on my hard drive > to see the date that I downloaded it. Usually that's enough to see how > old it is. If the patch didn't apply cleanly, the modified date would > show when I fixed it =). Just use the bloody dates instead of shortrefs. Cheers FRIGN [0]: http://st.suckless.org/patches/ -- FRIGN
[dev] dwm: fullscreen games
On Sat, 21 Nov 2015 09:19:07 +
Raphaël Proust wrote:
> See this thread http://lists.suckless.org/dev/1402/20190.html about
> that. I'm not sure if it still applies to current version.
>
> On 21 November 2015 at 00:46, Draco Metallium(Rodrigo S. Cañibano)
> wrote:
> > I'm loving this WM!
> >
> > I just made a quick hack to unfloat fullscreen windows.
> >
> > On 20 November 2015 at 16:23, Draco Metallium(Rodrigo S. Cañibano)
> > wrote:
> >> Thanks, I'll try that.
> >>
> >> But if you come to a more general solution(so it can be apply to other
> >> programs), I would be please to hear it!
I also came up with a patch... although I was trying to go the opposite
direction - make steam fullscreen games actually go fullscreen. After
reading your first post, I tested it with youtube, and it was able to
un-fullscreen youtube videos that played in the surf web browser.
This patch will let you toggle whether a window is fullscreen with
Mod+Shift+m. I use it like this:
1. start steam game
2. wait for game to load (most Source engine games use about 1/4 of the
screen and fill the rest with black)
3. after the loading screen, I hit shift+tab to bring up the steam
overlay, then I move the mouse outside of the tiny game window and hit
shift+tab again. This somehow breaks the fullscreen broken black window
and makes the game window floating. Now I can use mod+shift+m, and the
game goes into actual fullscreen mode.
I've been working on this issue on and off for weeks now... I can't
quite figure out why Source engine games don't correctly use the whole
screen in fullscreen mode.
I compared with how the games run in awesome:
1. start steam game
2. game starts up fine, using the entire screen. Window manager keys
still function.
Problem is... games started in awesome don't actually go fullscreen
mode. They go "borderless window" mode. I figured this out by chance
while fiddling with nvidia-settings... No v-sync, g-sync, or page
flipping.
Note that other games that don't use the Source engine often work fine.
Terraria goes fullscreen without issue. Faster Than Light also
works well (though it grabs the keyboard so I can't use window manager
keys).
So, dwm is able to correctly set fullscreen mode sometimes, but awesome
always successfully sets borderless window mode (even if the game wants
real fullscreen).
With some hacking of the dwm source code, I was able to make "rules"
that forced the problem games into proper fullscreen mode right as they
launched. But I'm still trying to figure out the proper way to handle
this (short of making a list of all the steam game window class names
and forcing them all fullscreen).
I'm thinking that the Source engine's linux fullscreen code is probably
broken, but dunno for sure.
--
Matt Boswell
diff --git a/config.def.h b/config.def.h
index 7054c06..60bbe3b 100644
--- a/config.def.h
+++ b/config.def.h
@@ -74,6 +74,7 @@ static Key keys[] = {
{ MODKEY, XK_t, setlayout, {.v = &layouts[0]} },
{ MODKEY, XK_f, setlayout, {.v = &layouts[1]} },
{ MODKEY, XK_m, setlayout, {.v = &layouts[2]} },
+ { MODKEY|ShiftMask, XK_m, togglefullscreen,{0} },
{ MODKEY, XK_space, setlayout, {0} },
{ MODKEY|ShiftMask, XK_space, togglefloating, {0} },
{ MODKEY, XK_0, view, {.ui = ~0 } },
diff --git a/dwm.c b/dwm.c
index 0362114..53c4a26 100644
--- a/dwm.c
+++ b/dwm.c
@@ -211,6 +211,7 @@ static void tagmon(const Arg *arg);
static void tile(Monitor *);
static void togglebar(const Arg *arg);
static void togglefloating(const Arg *arg);
+static void togglefullscreen(const Arg *arg);
static void toggletag(const Arg *arg);
static void toggleview(const Arg *arg);
static void unfocus(Client *c, int setfocus);
@@ -1515,6 +1516,14 @@ setfullscreen(Client *c, int fullscreen)
}
void
+togglefullscreen(const Arg *arg)
+{
+ if (!selmon->sel)
+ return;
+ setfullscreen(selmon->sel, !selmon->sel->isfullscreen);
+}
+
+void
setlayout(const Arg *arg)
{
if (!arg || !arg->v || arg->v != selmon->lt[selmon->sellt])
Re: [dev] designing a suckless bignum library
On Tue, Nov 17, 2015 at 6:11 PM, FRIGN wrote: > On Tue, 17 Nov 2015 17:52:59 -0200 > I'm already half-done with a suckless bignum-library. thanks for > pointing to the thread, but these guys are mostly talk and no do. > I bet the day when they reach consensus I'm going to offer > enterprise support for my then done bignum-library. I discovered a way to read the thread that makes it actually enjoyable. http://bbs.progrider.org/prog/read/1447711906/1,35,41,48,51,52,54,60 Looks suckless and the end goals are similar with yours, I think. Can't wait for a suckless a bignum so that sbase can have bc and be even closer to completion. Shipping sbase 0.1 must be a real dream of you. And of users/testers too of course. Good luck with all the work and the tight life schedules / limited free time. Have a nice one. > > On a serious note, the only thing stopping me from finishing > the library in a short timeframe is the fact that I've got a lot > of other things to do. > > Cheers > > FRIGN > > -- > FRIGN >
Re: [dev] sj: ucspi
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 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] designing a suckless bignum library
On Sun, 22 Nov 2015 00:12:47 -0200 Marc Collin wrote: Hey Marc, > I discovered a way to read the thread that makes it actually enjoyable. > http://bbs.progrider.org/prog/read/1447711906/1,35,41,48,51,52,54,60 > Looks suckless and the end goals are similar with yours, I think. > Can't wait for a suckless a bignum so that sbase can have bc and be > even closer to completion. Shipping sbase 0.1 must be a real dream of > you. And of users/testers too of course. Good luck with all the work > and the tight life schedules / limited free time. given things are never set in stone, if they actually come up with something suckless and it's working, there would be no reason not to accept it. It's always nice when people come together and work on something like that, so thanks for letting us know! sbase 0.1 is really a release which feels more like a 1.0 release. Once ed(1) is done, we're quite sure the release will happen. We can't ship a set of core utilities without ed(1). ;) Cheers and best wishes FRIGN -- FRIGN
Re: [dev] designing a suckless bignum library
Nobody uses ed ;) Jokes aside, I'll be looking forward to it. Have a nice one, see you around. On Sun, Nov 22, 2015 at 12:20 AM, FRIGN wrote: > On Sun, 22 Nov 2015 00:12:47 -0200 > Marc Collin wrote: > > Hey Marc, > >> I discovered a way to read the thread that makes it actually enjoyable. >> http://bbs.progrider.org/prog/read/1447711906/1,35,41,48,51,52,54,60 >> Looks suckless and the end goals are similar with yours, I think. >> Can't wait for a suckless a bignum so that sbase can have bc and be >> even closer to completion. Shipping sbase 0.1 must be a real dream of >> you. And of users/testers too of course. Good luck with all the work >> and the tight life schedules / limited free time. > > given things are never set in stone, if they actually come up with > something suckless and it's working, there would be no reason not to > accept it. > It's always nice when people come together and work on something like > that, so thanks for letting us know! > > sbase 0.1 is really a release which feels more like a 1.0 release. > Once ed(1) is done, we're quite sure the release will happen. We > can't ship a set of core utilities without ed(1). ;) > > Cheers and best wishes > > FRIGN > > -- > FRIGN >
Re: [dev] sj: ucspi
On Sun, 22 Nov 2015 03:21:12 +0100 Jan Klemkow wrote: > 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. Wow, you're fast. > 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. Ah, so I should let sj call tlsc instead of putting it on the command line. > 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). 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. Are you developing this from openbsd? explicit_bzero appears to be fairly new, and FreeBSD only got it as of 11.0. 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. > Thanks for reporting, > Jan You're welcome =) -- Matt Boswell
