Yup, that was it. Fixed in revision fa5cd0e6595d211591cc8eebfa81874b03b6162d.
What if you read the userlist? That's guaranteed to go to multiple screenfuls.
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
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
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
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
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
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
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.
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
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
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
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
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.
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.
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.)
I don't think so ... are you sure you aren't running up against the limit
of a server command length in Citadel?
You can comment out that line. Really. See
http://www.cygwin.com/ml/gdb-patches/2007-01/msg00258.html
for more information.
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.
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
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?
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: ***
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.
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.
Those last couple of commits I made seem to have improved things a bit. More
later.
I've been working with valgrind extensively and have been doing a lot of make
clean. This is a tough one.
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
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
templatize the summary (half baked)
I think you mean not baked. It's totally broken right now.
No, we just pull the top-level headers and we do not fetch the message body.
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.
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
This turned out to be nice and clean. It's going to eliminate a lot of
potential
(and existing) bugs.
Yikes. We're being Googled to death.
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
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.
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
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?
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
- 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...)
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
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.
I know this is an unpleasant thing, but have you been testing these commits
with Internet Explorer? Unfortunately we do have to support IE7+
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.
array be the smarter solution?
I wasn't planning to make the setting persistent across logins.
This update makes a change to struct wcsession; make clean if you're crashing...
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
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.
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
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.
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
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
Ok, we're good to go with 7.86
Works for me. Can we go right away or do we need to get anything else in
there?
I really do *not* see a need to rewrite the main loop of WebCit. It works
fine just the way it is.
According to what I'm reading it doesn't work on Solaris (with Sun's compiler,
not gcc).
I'm probably the wrong person to ask. I think everyone should be running
Linux.
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
Looks good so far. I also think that getting rid of all the extra complexity
has fixed the RSS reader crashes.
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.
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
Removed spurious calls to CtdlClearSystemContext()
Hopefully that's what was causing the problem. We'll know by tomorrow morning.
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
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
libev in webcit? Why? The main loop of webcit is simple enough. It doesn't
need libev.
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
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.
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
A source code management system approved by Ford -- that's a big deal :)
According to the logs we switched on 2010-aug-31.
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.
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
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.
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.
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
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,
Ok, I've built a VM on an IPv6 connected network for you to test with. Check
your email for the login.
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?
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
Yes, the chat window uses that API as well, and I believe I've fixed it.
The conversion of the existing Citadel code to dual-stack actually was far
easier than I thought it would be.
Even after you explicitly log out of one of the accounts? What does
logout mean in such a case? Is the message requested in the context of
the logged-out account, or the new logged in account?
Try it again now; it *should* theoretically act like any other web site
at this point. If
That was kind of nasty. I thought that it was me who broke the ajax stuff,
but it was actually the Prototype 1.7 upgrade.
Everyone take note of this please, particularly when using ajax_servcmd.
The parameters must be wrapped up inside EncodeURI() otherwise they will
be truncated.
There was, however, a problem with sessions not being *fully* logged out.
I have just fixed that.
I doubt we will ever have the ability to log in two different users at the
same time from the same browser. On the other hand, I have been adding go=
url components to a lot of the stuff I've
Getting more REST-like would probably fit in nicely with the anonymous
login feature. Any HTTP GET request received by webcit would require
webcit to ask citserver if the requested resource required
authentication, but then webcit wouldn't need to carry around much, if
any, state
That'll be quite useful -- I usually have to add temporary logging for just
that purpose while debugging various things.
It's been a productive evening. :)
Wiki now works and looks good, even in guest mode.
If I select edit, and save the page, I still see the same message. No home page is ever created.
Any advice here? Sam
I can confirm that it's definitely broken and I will fix it.
I am a staunch supporter of the GPL. On the other hand, the rhetoric from
RMS/FSF gets kind of tiring. I think ESR said it best in this editorial:
http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-28-023-10-NW-SM
(Oops ... the canonical location of this essay is:
http://www.catb.org/~esr/writings/shut-up-and-show-them.html
)
My intention is to completely remove the traditional login screen. All
authentication
will be performed through the modal dialog and ajax calls. Even on a closed
system that does not have guest mode enabled, the login screen will just
be a dumb banner with the login modal superimposed on top.
I haven't looked at this yet -- I've only isolated the problem message
and performed a backtrace. The message in question has been quarantined
in the Test Messages room (the subject is CAVE...).
When this message is read using webcit stable-78x, webcit dies in an
active loop. The looping
I thought this was going to be done in a separate branch?
Last call for bugfixes, otherwise I'm going to release 7.85 tomorrow in order
to get the networking fix into people's hands.
The dialog is built in such a way that we can probably re-use most of it for
other upload tasks. At the moment, I would like to focus on message entry.
Rewriting the upload dialog wasn't actually what I started out trying to
do. My goal was to eliminate all of the round-trips to the server
Qte! realy Qute. I'd like to add one todo... could you add a throbber
to the screen while its uploading the files on send? The one we also
show while loading the messages list in the mbox view?
Yes, that's definitely something for the TODO list.
Right now the problem is that I
have a look at that IG, its mostly what you did, plus wrap cunit
around it...
I wasn't familiar with CUnit so it's going to take me some time to figure
everything out, but it looks like you simply changed my assert() calls to
CUnit's equivalents, so yes, that's fine.
I will use
I try to re-use localizations when I can. The string Attachments: was already
in there.
its supposed to find the last left boundary?
The behavior of stripallbut() when multiple boundaries are found is
*undefined*.
However, my goal with this rewrite, aside from simplicity (and not crashing)
was to attempt to find the innermost string, so we don't end up extracting
a
where do you see QP exactly?
All I have to do is use WebCit to post a message in any room, and then read
it. QP-encoding all over the place.
Also: uploading files (attachments, images, etc.) is broken. The form data
stops when it gets to an upload file. It is important to repair this quickly
because I have a commit almost ready that will *greatly* improve attachment
uploading in webcit, but I can't test it until the MIME parser is
601 - 700 of 1679 matches
Mail list logo
