Blog | |
Releases |
Page:
0 ... 5 6 7 8 9 10 11 12 13 14 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100
Scribe Gmail Support | |
---|---|
Date: 24/4/2015 Tags: scribe | So Google have changed the authentication support for Gmail again, breaking the ability for Scribe to log in to any of the Gmail related services. Which means I'm going to have to put aside the v2.1 work temporarily to work on getting one of the support authentication methods working in Scribe. The options are:
The list of all official SASL mechanisms is here. PLAIN-CLIENTTOKEN is not mentioned at all. I wonder what implements that? Also of note, both XOAUTH and XOAUTH2 are marked "OBSOLETE". Nice one Google, supporting only obsolete, undocumented or non-functional authentication methods. |
(0) Comments | Add Comment | |
Scribe v2.1 Update | |
---|---|
Date: 21/4/2015 Tags: scribe | It may look like nothing is happening but really, there is. I have been toiling away on features and bug fixes in the v2.1 "trunk".
|
(0) Comments | Add Comment | |
The Current State of Scribe | |
---|---|
Date: 23/2/2015 Tags: scribe | Maybe it's time to just bundle OpenSSL in Scribe? I'm thinking of statically linking it so that it's always available and there will never be any trouble with missing or mis-matched libraries. The downside is the download size will blow out a bit. Over 2 MiB for the Windows build, maybe even 3. Recently I've had a very bad time with people have all sorts of weird crashes, odd behaviour and connection issues. And it seems that these things are next to impossible to reproduce. Maybe it's the target market changing on me as the profile of the client gets higher. One of those odd behaviours is Scribe not saving it's settings between sessions. I suspect this has to do with the install folder being write only, but the software thinking it's in portable mode (i.e. store settings in the install folder). I'd love for someone to be able to reproduce that and tell me how. So I'm going to look into ways of avoiding pitfalls. I'm starting to think that making automatic crash reporting default to "on" is for the best. I'm simply not getting enough data to respond to problems. The HTML editing functionality is coming along nicely. I managed to send quite a few HTML messages over the last few weeks. But it's still pretty flakey. And also there are some thorny issues to sort out. However it's a lot better than even a month ago so there is hope. Also I finally fixed an old crash in the GWindow destructor on the Linux/GTK2 build. The other main sticking point there is the popup handling under the GTK2 platform isn't great. But I didn't see the point in tackling that when the software was still crashing all the time. Edit: So I think I've worked out the procedure for the not being able to save your settings bug:
|
(0) Comments | Add Comment | |
Scribe v2.1 | |
---|---|
Date: 27/1/2015 Tags: scribe | So the v2.0 builds are basically stable as far as I can tell. Although there is some issues with some people connecting to SSL servers and one report of a crash at startup on MacOSX 10.10 (which I'm investigating). In the light of that I'm shifting my attention to the features in the v2.1 branch. I want to go through the things I'm aiming to get into that release:
I'm looking to get the first build out sometime in Feburary. |
(0) Comments | Add Comment | |
"Invalid HTTP Request Headers" in Firefox | |
---|---|
Date: 9/1/2015 Tags: firefox | For most of 2014 I've been using Firefox because I feel it's doing a better job of looking after my privacy. However it's not without it's cost. For instance today I found some pretty quirky behaviour in the Mac build of Firefox v34.0.5: Basically on this site it's dropping the leading "G" of the "GET" request. To make matters worse the problem is intermittent. I can reproduce with a clear cache. Internally Firebug is reporting the correct packet, but Wireshark shows the missing byte. |
(0) Comments | Add Comment | |
Portable OpenSSL on Mac OS X | |
---|---|
Date: 12/12/2014 Tags: dylib openssl | So it's been brought to my attention that Scribe's self install of OpenSSL on Mac doesn't actually work in v2.0.x, so the last week I've been looking into what it takes to do that. The main issue is that load paths, are by default, absolute and hardcoded. Which works against you when you want a portable install of something. Secondly the OpenSSL .dylib is made of 2 libraries; libssl and libcrypt. And when you dlopen the first (libssl) the system needs to be able to find libcrypt. The link is embedded in the Mach-O image as a LC_LOAD_DYLIB segment. You can see that by issue the command: otool -l ./libssl.1.0.0.dylibPart of the output you'll get: cmd LC_LOAD_DYLIB cmdsize 64 name /usr/lib/libcrypto.1.0.0.dylib (offset 24) time stamp 2 Thu Jan 1 10:00:02 1970That absolute path is what is causing the dlopen of libssl to fail. So we need to fix that. And the tool to do it 'install_name_tool', which is provided from Apple. Now I had two problems. Firstly what do you change the path to? And how do you actually get the tool to change the path? Firstly Apple has several ways of locating shared libraries:
@executable_path/libcrypto.1.0.0.dylib But how to call install_name_tool to actually do that? Well to start with I tried: install_name_tool -change /usr/lib/libcrypto.1.0.0.dylib @executable_path/libcrypto.1.0.0.dylib ./libssl.1.0.0.dylibWhich is actually the right command. But because the new string is longer than the old string the command fails (silently I might add). The trick to getting it to work is to add the linker command: -Wl,-headerpad_max_install_namesto the CFLAG variable in the OpenSSL root Makefile. This causes the load segments to have extra padding bytes so that you can change the paths as much as you want later. Now after rebuilding the OpenSSL dylibs you can reissue the install_name_tool command and the link path changes: MacOS matthew$ otool -l ./libssl.1.0.0.dylib ... cmd LC_LOAD_DYLIB cmdsize 64 name @executable_path/libcrypto.1.0.0.dylib (offset 24) ...Then I could dlopen 'libssl.1.0.0.dylib' and it would pull in the right libcrypt file (both as sitting in the same folder as the executable). I'm putting this here so I don't forget how to do this next time. Ha. |
(3) Comments | Add Comment | |