[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. c12b418a64b44be9d08cae0e5dd25c988a522b90
The conversion of the existing Citadel code to dual-stack actually was far easier than I thought it would be.
[Citadel Development] Re: 303 Status response
This would work quite nicely with my current efforts to remove all of the round-trip form submissions in the system. For example, in the message editor, we no longer submit the form when adding attachments. It is my intention to validate recipients before sending the form as well. And in the calendar view, I would like to do free/busy checking without a submit.
[Citadel Development] (no subject)
so, first site with the libev based smtp client has just gone live... Do you need a machine on an IPv6 network to test it with?
[Citadel Development] Re:
Ok, I've built a VM on an IPv6 connected network for you to test with. Check your email for the login.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
Ok. This solves the problem of I can request arbitrary msgnums and the server will give them to me whether or not they exist in a room to which I have access -- which was only a minor nuisance before, but with Citadel sites being exposed to the public Internet with anonymous guest mode enabled, that would have become quite a large problem. Imagine how lovely it would be if Google indexed it all. :) Unfortunately it takes a little more memory than I wanted it to.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. e432540ab02282396bf87eafde6a1698819912ff
This may all be true. What I'm *not* willing to do is go to disk to check the msglist for the current room before each and every message fetch. I'm sure the tree will be quite unbalanced after the user visits one room, since it is loaded linearly. As other rooms are visited it should theoretically begin to even out. I tried a different approach at first, where we cached the msglist loaded during any CtdlForEachMessage() operation, and then checked it later. It worked *most* of the time, but there were some edge cases where it simply didn't work. For example, when saving a calendar event, we were heading over to the My Citadel Config room, which burned the cache for the calendar room, and then going back to the calendar room and requesting a specific message number we already knew. That would fail every time. There is the possibility of caching the msglist when we first arrive in a room, but that could have an effect on interactive performance as well.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. cc9210c238de95ad2005ef023897dbf5acecc31d
I'm a little hesitant to put that into 7.xx because I don't know how we fixed it. Somewhere along the line we did something to the I/O layer that made it stable enough for XMPP over TLS to work, but I don't know where or what.
[Citadel Development] (no subject)
Ok, a quick update: So far I've been able to reduce the crashes, at least, by reducing the load on the system a bit: 1. I've taken the IP addresses of all the hosts that are trying to email room_citadel_stats 5-6 times each minute and firewalled them out, so they can't do that anymore. 2. serv_rssclient was running once every minute. I've changed this to no more than once every 15 minutes. In the last 8 hours or so it hasn't crashed. We are still experiencing the problem, however, where client sessions are occasionally disconnected without any reason. I don't know why and this is the #1 priority to fix.
[Citadel Development] (no subject)
The problem uncensored is having appears to be reproducible on any Citadel server running the current code. Here's how to reproduce it: 1. Start your Citadel server 2. Run several copies of this script, which will show you exactly when your connection dropped: #!/bin/bash ( while true do echo 'time' sleep 1 done ) |nc my.citadel.server 504 3. Run one or more copies of this script, which rapidly builds and breaks connections: while true; do echo '1 NOOP' | nc my.citadel.server 143 ; done 4. Let it run for a few minutes and you should see everyone drop at the same time.
[Citadel Development] (no subject)
This might be a race condition of some sort. If I put a one second sleep between each connection in the second script, it doesn't cause the first script to drop anymore.
[Citadel Development] (no subject)
A source code management system approved by Ford -- that's a big deal :) According to the logs we switched on 2010-aug-31.
[Citadel Development] (no subject)
If it were just me, I'd still be quite happy using CVS. I didn't see the point of switching to svn and I really didn't see the point of switching to git either, when CVS was doing the job.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 51a3c9712abdd33ec5871c40a7ae0354110b1883
There's gonna be a huge update coming up as soon as I get things running smoothly again. This is mainly intended to reflect the future migration to a libev-based architecture. The Citadel server is built as a state machine, so the libev move does make sense. This is fundamentally incompatible with the davew thread system, unfortunately -- it's brilliant code but it basically implements an entire multitasking operating system inside the application, which we really don't need. Since it's currently causing stability problems I am removing it. Step 1 will be to go back to the old threading architecture. Step 2 will be to migrate to libev. Then the server will be even *more* of a state machine.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. d8e37b83842f3724e21da6d191a86d91cd3f3f80
And maybe it's my imagination but I could swear it's faster this way. At the moment I'm using a fixed size thread pool. There are eight worker threads, one master socket listening thread, and one supervisor thread. I haven't decided yet whether I want to move the master socket listener back into the worker pool. What I can tell you is that I intend to make citserver's thread pool expansion algorithm identical to webcit's: start with a very small number of threads, and spawn a new thread whenever it is determined that there is 100% utilization, up to a fixed limit. There is no reduction of the pool size. I think any further architecture decisions will be based upon a discussion of how libev will eventually work. I am hoping that libev could eventually become the main loop for all worker threads.
[Citadel Development] Re:
There does seem to be a problem. When citserver is first started there is no problem, but after it runs for a little while, messages are getting corrupted as they are read into the buffer for sending. The symptoms showing up in the log are that the From: address is not extractable (so it's sent to the recipient as MAIL FROM: some...@somewhere.org ) and that we get the warning that the message did not end with a 0x10. I've temporarily added a diagnostic that dumps the buffer to /tmp/badmail.x.x when this condition is detected.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 1472e247d25c64dd52a1e0d8166946c003b74581
libev in webcit? Why? The main loop of webcit is simple enough. It doesn't need libev.
[Citadel Development] Re:
I don't think we have the horsepower to run Uncensored under valgrind. It was bad enough when I constrained its I/O speed a little bit during the last migration -- the system was practically unusable. For the time being I have added a check to see whether msg_size is 0, and if it is, we syslog the problem and then 4XX defer the delivery instead of attempting delivery and losing the message. We can work on this problem in a bit more relaxed fashion as long as I know we're not throwing away mail.
[Citadel Development] Re:
Ok, here's more info on the problem: When the problem starts to happen (again, right after TDAP runs) -- CC-redirect_buffer no longer works for housekeeping threads (bound to masterCC). This means that the fulltext indexer is coming up with blanks too, which I've tentatively verified.
[Citadel Development] Re:
Perhaps I can run tests on a *clone* of Uncensored's db. Over the last two days I've seen the problem begin after the 04:00 hour; this happens to be when we run TDAP so it's definitely possible that we're looking at a memory issue of some sort. It might even be a massive memory leak triggered by TDAP, but I'm really suspicious as to why the only thing it seems to be affecting is outbound mail delivery.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Removed spurious calls to CtdlClearSystemContext() Hopefully that's what was causing the problem. We'll know by tomorrow morning.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 842319fa33527c94e5ea7dc60e3b4942ad4c7ecc
Looks good so far. I also think that getting rid of all the extra complexity has fixed the RSS reader crashes.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
According to what I'm reading it doesn't work on Solaris (with Sun's compiler, not gcc).
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 2063519eeba1e97c13732f061faea42556e9488b
I'm probably the wrong person to ask. I think everyone should be running Linux.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 98077cf98a82f673c2bc0486e32187c30c267eb4
For a post-8.00 design, would it make sense to use libev as the housekeeping loop? Then it could take care of SMTP delivery along with everything else the server needs to do in the background, and we can dedicate a thread to it (either the supervisor thread or a different one) -- and then the ordinary worker threads can be used for interactive sessions.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 98077cf98a82f673c2bc0486e32187c30c267eb4
I really do *not* see a need to rewrite the main loop of WebCit. It works fine just the way it is.
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. 3d8a628f35f644af871e19d9b6a2a30fb66d88a7
Works for me. Can we go right away or do we need to get anything else in there?
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. c08adcea52e85d6139ad158c17eb3d1941df2eb5
Ok, we're good to go with 7.86
[Citadel Development] (no subject)
Interesting observations. It's definitely a work in progress but I'll make a note of those observations as we tune it. Admittedly I'm not all that great a UI designer, so every little bit of feedback helps. I do like having the icons but I think it's beginning to become a problem that we use the same icons over and over again. Fortunately, the quantity, quality, and variety of freely available icons is much better now than it was half a decade ago, so if we added some more we wouldn't have to spend money on this a second time. Thankfully, we are at a point now where the code is stable enough that I can deploy the good builds to Uncensored so everyone can see the development progress.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
Thanks for ignoring what it means to do a coordinated release between different products and vendors... I guess that was the first and last advanced notice for citadel, at least from my side. You were expecting something different? 100% of the security advisories to which we have responded in the past have involved coordinated disclosures in which a published security advisory is able to indicate to end users exactly which versions of various applications are invulnerable at the same time as they are advised of the vulnerability in earlier versions. If you were expecting to operate by some other protocol then perhaps you should have outlined that in advance instead of being sarcastic when you are misunderstood. We have the fix in our tree. There has not been a new version of the software published, nor has there been an advisory posted to our user community. What is it specifically that you are expecting us to do at this time? -- A
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
oops. gotta fix that. We're going to hold off on any releases for now, though. The guy chose some weird non-standard disclosure method and then got his panties in a bunch when I misunderstood it. Normally a coordinated disclosure means that everyone's got a patched version available for download at the time of disclosure. These morons want to have everyone hold off on any patches (including public source code repos) until the disclosure date. I'll hold off on a release until then but I'm not going to stop using git the way it was intended.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
I think that method is stupid and I'm not going to follow it. In the real world, coordinated public disclosures include an advisory that says upgrade to version x.yy in order to protect your server against this vulnerability.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
I'm willing to hold off on releasing our own security alert, and even perhaps waiting until 0 Day to release an updated version of the software. What I'm *not* willing to do, is to stop using our source code repository the way it was intended because some tinfoil-hat thinks that someone's going to monitor it for potential abuses.
[Citadel Development] Re: Embargoed: multiple jabber servers vulnerable to denial of service
You know what, I am not really interested in working with people who feel the need to tell me exactly what they want me to do, so it's ok. I would much rather accept security alerts from people who do it the normal way.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 69d7c37613081132e8476550c9810d7633d23fde
This update makes a change to struct wcsession; make clean if you're crashing...
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 69d7c37613081132e8476550c9810d7633d23fde
array be the smarter solution? I wasn't planning to make the setting persistent across logins.
[Citadel Development] Re: bugs and inconsistencies
The command ARTV is not documented on http://www.citadel.org/doku.php/documentation:appproto:start ARTV is deprecated. It has been replaced by MIGR.
[Citadel Development] Re: screenshots showing latest commits: Calendar and Chatroom
I know this is an unpleasant thing, but have you been testing these commits with Internet Explorer? Unfortunately we do have to support IE7+
[Citadel Development] Re: screenshots showing latest commits: Calendar and Chatroom
Microsoft will always find new ways to suck. Fortunately their reign seems just about over and hopefully in a decade or so we will not have to worry about them. By the way, I applied the git commit-filter you requested.
[Citadel Development] Re: [SCM] citadel.org branch, stable-78x, updated. v7.86-13-g3f0e1c3
Please don't! We have some functions in our automation framework that do a similar check to allow our scripts to access external files in place of a DUT command and it's ended up causing issues when some of the commands contain a / character. Despite the fact that I don't understand what you just said, I have to point out that the reason I did that ended up becoming somewhat irrelevant anyway. I was hoping to allow Citadel to connect to ClamAV via a unix domain socket, but it turns out the protocol sucks and needs a second channel on the network anyway, so that won't work out. Blah.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. dd31b4fd8b79ae81d966ecb923586153c4af966c
- wrap this into subst.c:StrBufAppendTemplate() with a new escaper char? (maybe 'C'?) We can't use CDATA blocks in templates. CDATA is only valid in XML, not HTML (unless you're using XHTML, which we are not...)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. dd31b4fd8b79ae81d966ecb923586153c4af966c
Fair enough -- I'm not satisfied with what I did, though. I'm going to change it around a little more. Right now the feed generator is spitting out every line as a CDATA block while it reads those lines from the Citadel server. I need to buffer the whole thing and then output it as a single CDATA block, which sounds like a job for StrBuf.
[Citadel Development] Re: Citadel RPM repository
If it is your intention to keep these RPM's up to date, I would love to designate your repo as the official one. Can we name you as the official maintainer on an ongoing basis?
[Citadel Development] Re: setup bug
modules/blog/serv_blog.c: In function 'blog_upload_beforesave': modules/blog/serv_blog.c:77:13: error: 'BLOG_EUIDBUF_SIZE' undeclared Update your libcitadel.
[Citadel Development] (no subject)
stable broken? gcc -I/var/lib/citadel -Wall -g -Werror=format-security -O2 -Wall -Wcast-qual -Wcast-align -Wstrict-prototypes -D_REENTRANT -pthread -I ./include/ -I. -I ./include/ -DHAVE_CONFIG_H -c modules/wiki/serv_wiki.c -o modules/wiki/serv_wiki.o modules/wiki/serv_wiki.c: In function âwiki_revâ: modules/wiki/serv_wiki.c:593: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:593: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:594: error: âCitContextâ has no member named âcached_num_msgsâ modules/wiki/serv_wiki.c:595: error: âCitContextâ has no member named âcached_msglistâ modules/wiki/serv_wiki.c:596: error: âCitContextâ has no member named âcached_msglistâ Oops. That means I backported a patch to fix a bug that didn't exist in that version. :(
[Citadel Development] Re: Replacing TinyMCE by CKEditor
After a very short comparison of usability, I propose we give ckeditor.com a try (again?). dothebart mentioned we might have used that one before. This is a short list of reasons why I prefer ckeditor: If it seems better, then I have no particular attachment to TinyMCE and would be willing to try CKeditor instead. I do have one requirement coming up soon: in the not too distant future I would like to add the ability to embed images into messages directly. Presumably this would take the form of first uploading them as attachments, and then the editor would need to know about them so it could offer them to the user. The editor will probably need to know their CID's. I'm not asking you to implement this (unless you're feeling ambitious) but merely to ensure that the possibility to implement it exists.
[Citadel Development] (no subject)
Yikes. We're being Googled to death.
[Citadel Development] Re:
Actually, I'm in the process of ripping out the *new* way too. The buttons for Reply, ReplyQuoted, and Forward need to carry a whole lot of information (subject, references, recipients) out to the browser and then back in through a URL submission, and because those buttons are passed through the GetLoggedInFirst() framework, their URL's need to be double-escaped. As a result, there are a number of special characters which can break the whole thing if they appear anywhere. Instead of trying to tweak this fragile and ugly situation, I am rewriting it to have the browser simply tell WebCit the number of the message being replied to (or forwarded), and WebCit can fetch all of that information on its own. We already do this for the quoted/forwarded message text, so it should be fairly straightforward to get all the other info too. (I said straightforward rather than easy because the tricky part will be to do it without fetching the message three or four times.)
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
This turned out to be nice and clean. It's going to eliminate a lot of potential (and existing) bugs.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
No, we just pull the top-level headers and we do not fetch the message body.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 7bfc9ea85ba1146f09982b9616eaf82b54321ea4
Good question, and the answer is yes. This is all done within webcit, so it is incapable of bypassing the citadel server's security model.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 9a890c12b27110a519bda6b3c80b812e611be6cf
templatize the summary (half baked) I think you mean not baked. It's totally broken right now.
[Citadel Development] (no subject)
I noticed about a week or two ago that Uncensored has stopped auto-purging users other than SYS_Citadel. It could theoretically be Eagle eye there. :) But it's no cause for concern -- I increased the user purge time so it'll be a while before DAP kills anyone. Good catch though.
[Citadel Development] (no subject)
IG, please note, that if Hdr-HR.DontNeedAuth is set, no server connection or session is needed, so that name might be a little misleading and you might want to change it. I was wondering what that was about. So it doesn't mean no login is required, it means that no connection to Citadel is needed?
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. 0ff2052c39dd1229a93f6d72424275908e203669
I've been working with valgrind extensively and have been doing a lot of make clean. This is a tough one.
[Citadel Development] Re: [SCM] citadel.org branch, master, updated. ceffa8fd6967b780a9e74d97a2e49d375d64a4a4
Those last couple of commits I made seem to have improved things a bit. More later.
[Citadel Development] (no subject)
should this just list rooms which are public subscribeable or our new public rooms too? else maybe the documentation needs to be altered imho? I don't think there is any difference? If you are running an open system then the public rooms are the ones reachable without a login.
[Citadel Development] Re: CONF GETSYS
Well, the form of those commands is fairly straightforward; the trick is in knowing the format of the system configurations that are to be loaded and saved.
[Citadel Development] Re: [SCM] citadel.org branch, libevent, updated. 2d65a22caf6157e3a4759e5e17cb2bbd1d5934a9
lib/stringbuf.c: In function 'StrECMAEscAppend': lib/stringbuf.c:2216: error: 'IsUtf8Sequence' undeclared (first use in this function) lib/stringbuf.c:2216: error: (Each undeclared identifier is reported only once lib/stringbuf.c:2216: error: for each function it appears in.) make: *** [lib/stringbuf.lo] Error 1 The build is broken, please help --
[Citadel Development] Commit logs now going to a different room
Attention please: Due to the excessive volume of commit logs being posted to this room, all commit logs will now go to a different room called Citadel Commits . It is a hidden room but it is accessible to everyone. Please go there if you wish to view commits. You can also subscribe to it as a mailing list.
[Citadel Development] (no subject)
attachments uploading doesn't work with iceweasel7 ok with chromium though... Tested with Firefox 6, and it works. There is no Firefox 7. Is IceWeasel 7 a production browser?
[Citadel Development] Re: undefined reference to `XML_StopParser'
You can comment out that line. Really. See http://www.cygwin.com/ml/gdb-patches/2007-01/msg00258.html for more information.
[Citadel Development] Re: undefined reference to `XML_StopParser'
Aha! In fact, we did XML_StopParser() specifically to handle that vulnerability. (The guy who sent out the alert was a real asshole about it too.) So we just need to change the XML_MAJOR_VERSION we're looking for from 0 to 1 and that will take care of it, as your patch demonstrates. Thanks!
[Citadel Development] (no subject)
I don't think so ... are you sure you aren't running up against the limit of a server command length in Citadel?
[Citadel Development] (no subject)
I believe we set our limit to 1024 characters in order to match other protocols such as SMTP/POP which have their line limits set in the same place. (No strbuf here please; doing so would create a cascading set of bugs that would set us back by a year or more.)
[Citadel Development] (no subject)
not that clever. The lack of cleverness comes from having dumbed it down -- a lot. We went through a number of incidents where the IGnet config was being completely lost on some systems, causing all networking to stop.
[Citadel Development] (no subject)
Well, it looks like networking broke sometime around the beginning of May. I'm posting this message to dogpound2, so I guess when I see it on Uncensored we'll know we fixed it.
[Citadel Development] (no subject)
Listen up, folks: since parts of the 8.00 code seem to have accidentally been released (and I still can't figure out why, but I'm assuming it is my fault) we will release Citadel 8.01 *TODAY*. This will be a soft launch like we did last time: the code will go gold but we won't do a big announcement until after our first bugfix release. This will also give us some time to update the web site with new screenshots, etc. git master will continue to be in deep freeze (serious bugfixes only) until after the release.
[Citadel Development] (no subject)
I'm still not sure how it happened. We're pretty careful about having all of the release scripts track a stable branch of the code. I think something got backported that shouldn't have. Anyway, the Easy Install site is now tracking git master. I have a couple of little things to do and then we'll tag 8.01 and build tarballs etc etc.
[Citadel Development] (no subject)
Hey everyone, sorry for my relative silence for the last week or so ... I've been building a new version of the Citadel virtual appliance, using a scripted installation this time so that the appliance itself can be regenerated at any time, on any hypervisor. I'm just about done and will initially publish downloadable versions for VMware and KVM. If I can get an OpenVZ one running (which shouldn't be too hard because the new appliance is based on Debian) then I'd like to try to get into the ProxMox VE template library too. After that's done I'm going to update the screenshots on the web site. They need to not only reflect the new look of Citadel 8, but also they need to be bigger and they should slide around and highlight different reasons to look around the web site, which seems to be the trend now. Citadel 8.01 is still in soft launch mode right now. Easy Install and tar.gz both offer 8.01 at this time, and no one seems to be having any big problems, which is good news. Are the .deb and .rpm packages of 8.01 built yet?
[Citadel Development] (no subject)
I sure wish I was coding, but there's so much else to work on right now... I spent the evening redesigining the front page of http://www.citadel.org The page looks a little more modern now. It's tough, as a hacker, for me to reduce the amount of information on that front page. I want to give everyone as much as I can right away. But, business sense and a review of what others are doing seem to dictate that the front page should just capture viewers' attention and then lead them to more information. So, that big banner which takes up most of the screen will eventually rotate between three or four different banners, each highlighting a different reason why you should use Citadel. One of them might even jump on the cloud computing hypewagon and point out that Citadel integrates perfectly with infrastructure as a service architectures. The tag line will of course be Castle on a Cloud big stupid grin
[Citadel Development] Re: webcit logging questions
Ooops. Gotta remove those command line options. citserver and webcit both use syslog() now. Each program is also set up so that if run in the foreground, it will log to stderr as well.
[Citadel Development] Re: systemd
I'm looking into systemd stuff right now. I'm not sure if citadel is systemd ready (I haven't tested it yet), but this document (http://0pointer.de/public/systemd-man/daemon.html) describes systemd's requirements on a daemon. May be it's of interest for someone. Irrespective of what systemd wants, that looks like a pretty good checklist of things a program ought to be doing when running as a daemon. I'll make a note of it and run through the list when I'm done squashing this ONE LAST BUG that's been holding up the 8.02 release. (I did make a lot of progress on it and we're almost there!!)
[Citadel Development] (no subject)
IG: What about citserver's -t trace_file option? Should it still work? Not anymore. It is a vestige of the old logging system which has been completely replaced with syslog. I do see that if you specify the -t option it will create the file and then do nothing with it; this has been fixed as of today.
[Citadel Development] Re: Warnings
The Free Software Foundation address in this file seems to be outdated or Ok, that's fixed. I see that they now want you to publish their web address instead of their street address, and that's fine. I've switched to the new suggested declaration, except the words free software have once again been replaced with open source software because this is software designed to actually be used instead of to have people like RMS sit around and talk about freedom
[Citadel Development] (no subject)
I've started my own implementation of OpenID 2.0 Relying Party support. After re-reading the specification for the protocol, I've decided that it's doable, it's just going to take some time -- but it's worth doing, far more so than trying to link in libopkele and add C++ dependencies. For those of you following along at home, a couple of years ago (more than a couple of years ago?) I looked at OpenID 2.0 and noticed that there were a half dozen specifications competing to be the one used in the new version of the protocol, so they did a design by committee type thing and ended up mashing them all together. Yuck. OpenID 2.0 requires XRI support, but it appears *nobody* is using XRI. Nobody wants it, nobody is asking for it, and none of the OpenID providers out there seem to be offering it, so we can safely skip this part of the protocol. It also requires Yadis. There doesn't seem to be any way around this. Google, AOL, and others are using the Yadis discovery protocol and generating XRDS documents. Fortunately we can implement Yadis discovery using libcurl and expat, and a bunch of our own code wrapped around that. I'm sure there will be other pitfalls as we go along, but right now I'm just working on implementing the discovery part of the protocol. The good news is that once we have this in place, we'll be able to support not only OpenID on its own, but lots of other single sign ons. OpenID is used by Google, Yahoo, AOL, Microsoft ... pretty much every major service except Facebook. When you see a login box that offers lots of different login options, most of them nowadays are just using OpenID but the site knows the discovery URL to use for that service and fills it in for you.
[Citadel Development] (no subject)
I've finally finished the implementation of OpenID 2.0 authentication (relying party) support. There are only two places where we go to the web using libcurl. I was happy to discover that there were no changes required to the Citadel server protocol, and therefore no changes required in WebCit. I will, however, follow up with WebCit changes that allow a user to sign in using Google, Yahoo, and AOL without even knowing that they're using OpenID. The only thing missing right now is the Simple Registration extension. This is the piece that allows OpenID providers to provide a screen name, location, gender, date of birth, etc. to Citadel, further simplifying the login process. That should be a *fairly* quick thing to do since we did it in OpenID 1.1 and it hasn't changed by a whole lot (I don't think it did anyway). As soon as Simple Registration is completed I will be merging it into git master. Only one file (serv_openid_rp.c) has changed.
[Citadel Development] Re: TXT client ignores fullscreen=yes and local_screen_dimensions opts
What if you read the userlist? That's guaranteed to go to multiple screenfuls.
[Citadel Development] ALL PACKAGERS PLEASE PUSH CITADEL 8.03 IMMEDIATELY
Attention all Citadel packagers! Please push the current contents of git master as Citadel 8.03 release IMMEDIATELY. The code contains a fix to a VERY SERIOUS bug that is causing upgrades to fail and email aliases to be lost, causing incoming mail to bounce. There is no risk of data corruption and no security vulnerabilities; however due to the issue of bounced mail I am considering this to be a HIGH PRIORITY update. cc: Citadel Development room, Citadel Packaging room.
[Citadel Development] (no subject)
Ok, I think this has something to do with the fact that the screen dimensions are not detected until after the user logs in. Perhaps I can move that since we are no longer tracrecording manually configured screen dimensions on a per-user basis.
[Citadel Development] (no subject)
Yup, that was it. Fixed in revision fa5cd0e6595d211591cc8eebfa81874b03b6162d.
[Citadel Development] (no subject)
Branch stable-78x is now retired. (Any packagers who want to maintain it are free to do so, but upstream is now officially retiring it.) Branch stable-80x has been established. I would like it to be short lived. dothebart is going to begin merging master and libev.
[Citadel Development] (no subject)
Ok, that's fine -- however I did notice that when I attempted to build Citadel using an older version of libev/c-ares, I didn't get a configure error saying that was the problem. Instead, the build simply failed with a bunch of obscure errors. Shouldn't the configure script check the version?
[Citadel Development] (no subject)
I added a configure check for libev version. I couldn't figure out how to do it for c-ares though. Is there perhaps an API call that is only available in the new version that we can check for?
[Citadel Development] (no subject)
ares_parse_mx_reply is the reason why we need a recent version; it was added about a year ago by the node.js guys. Ok, that worked really well. Now we can check for the right version. Is there a similar function we can check for in libev? If so, then we can look for that instead of running a test program to evaluate the version number.
[Citadel Development] Re: Net::Citadel in Debian
That's part of why I don' t do much with Ubuntu...g   I've been doing a lot with Ubuntu lately. Most of it involves trolling any story on the web that mentions Ubuntu and leaving a comment about how Ubuntu has jumped the shark now that they're forcing Unity on everyone.
[Citadel Development] (no subject)
hm, a datatype which doesn't exist in the never version is not enough? for shure there are also the functions initializing them ev_cleanup_init() is defined as a macro. I went with ev_cleanup_start() instead. Is that definitely a function that only appears in libev 4, not libev 3?
[Citadel Development] (no subject)
Right. We're not actually calling that function from citserver; we are merely checking for its existence in order to make sure we have a new enough version of libev. I have also decided to make zlib mandatory from now on.
[Citadel Development] Re: Net::Citadel in Debian/Ubuntu
Cool. What's the official upstream web site for Net::Citadel ? I want to make sure we have it listed correctly on www.citadel.org
[Citadel Development] (no subject)
currently its rather a concern howto do rate limmiting so citserver doesn't overrun peers or even the DNS server when doing a massive delivery... We probably want to have a maximum concurrent background tasks setting, or something to that effect. At the moment, restarting citserver on a busy site causes the whole thing to get hammered as it attempts the entire queue at once. Retry for SMTP is at the discretion of the sender, but the way we implemented it before was to retry in (I think it was) 15 minutes, and then double the retry time after every failed attempt up to a maximum of four hours, and then keep trying every four hours until five days has passed.
[Citadel Development] (no subject)
We'll have to recheck that. I didn't see any when I tested it. Speaking of which, I've also put a wholist into ctdlsh. It reuses the code from the defunct 'whobbs' utility, although all I really ended up keeping was the printf() calls that show the output. More importantly, ctdlsh now uses the citadel-admin.socket to connect to Citadel server, so this unfinished and non-supported utility now works again :) It's a happy fun thing because it's the last bit of code that was still trying to read citadel.config directly, as far as I know. In the not too distant future, there will no longer be an on-disk 'struct config' with a persistent format. I want to change it to a key/value store so we no longer have to modify code in three different places when a new config value is added. And of course all of the c_niu_* members are starting to look pretty bad.
[Citadel Development] Re: How did I make my sieve filter work again
I wonder if we should simply drop support for Sieve and parse the rulesets as they are.
[Citadel Development] Re: Please don't drop sieve
Ok, well in any case you don't have to worry about losing mail. The way our implementation works is that Sieve runs *after* a message arrives in the user's inbox. The absolute worst case scenario is that a message is left in the inbox. Other software does this as well. Thunderbird for example will briefly flicker a message into your inbox from time to time before it gets handled.
[Citadel Development] (no subject)
IG, regarding your rework of sendcommand setup... Is password recovery going to continue working? Yes, in fact it works better now than it did before. You just run setup and it does the right thing; it will even extract the correct admin password and let you verify and/or change the password. We inadvertently released a couple of versions where this didn't work at all because davew didn't understand what the master user function was for (hint: it's not an administrator)
[Citadel Development] Re: How did I make my sieve filter work again
sieve2_validate() returned 12: Sieve Error: script was not retrieved This error results from an empty script being fed into the Sieve parser. I have committed a change that will check for this condition and stop processing instead of throwing a spurious error. The bit about eating the first character of the script is concerning. Right now I am looking into a WebCit problem that is preventing the display of the form that allows custom scripts. After I resolve that, I'll see what's happening with the first character.
[Citadel Development] Re: sample of filter w/space eaten and why my filter don't work?
Ok, the behavior of the Sieve parser itself is beyond our control because it's a third-party library; perhaps an inquiry with the developer of libSieve might be in order. I'm more concerned with the characters being eaten. Can you show me the original line of script and what it looked like after it was mangled?
[Citadel Development] Re: sample of filter w/space eaten and why my filter don't work?
Ok, I'm still planning to work on this, but I got sidetracked when I went to test it -- discovering that when the Sieve editor was templatized, huge chunks of functionality were simply omitted. I have to put it all back before I can see why a character is being stripped.
[Citadel Development] Re: libev location
In the next iteration of Easy Install, I intend to build libev, c-ares, libsieve, and maybe even libdb as static libraries. Since they're not shared, there is no point in going through the rigamarole of handling them as dynamic.
[Citadel Development] Re: sample of filter w/space eaten and why my filter don't work?
Ok, it's time to test Sieve again. (updated in git and in Easy Install, so far...)
[Citadel Development] Re: systemd: socket activation
Looks like a nice idea. Will we server software developers have to account for this if distribution vendors adopt it?
[Citadel Development] (no subject)
Looks like the RSS reader has been stuck since April 3.
