Re: [PATCH] RemoteDelivery support for multiple delayTimes
On Friday 24 October 2003 21:47, Noel J. Bergman wrote: Søren, We might do some further tweaking, but I think you've got the right idea. The thought I have is that (down the road) some code might want to accept messages based upon other criteria, so we might want to enlarge upon our options there, possibly by using introspection. A few minor items: (1) Could you submit against branch_2_1_fcs? Yep, will do that. (2) The spool is purely internal. Let's chance accept() to return the message. Okay, I guess you want this for all three accepts. (3) Please see GenericRegexMatcher.java for correct usage of the regex code in a multithreaded environment. We need to compile as READ-ONLY, and create a matcher in the executing thread. But is the regex done from muliple threads? Only if init() can be called from multiple threads, and at initialization time we are not particularly pressed by performance issues, so I did a synchronized (MATCHER) in the Delay constructor. But I have no problem doing it the other way. I also discovered a minor mistake in my patch, as the new accept method implementation in JDBCSpoolRepository does not enforce the minimum delay set by WAIT_LIMIT, will fix that as well. Expect a new patch tomorrow. --Søren I'd like to get this change included in our next release. The spooler has never been exposed to anyone, and there are only two calls in the codebase. The James code didn't follow the correct usage pattern for regex previously, but it is documented by the regex classes, as I discovered when trying to do some other things with them. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote: He's not questioning whether it's encrypted. His point is, doco sends an email to an address, and you respond. It gives very little control, even if there is a compromise. AIUI, the proposed solution would allow anyone to edit content, and contribute it as a patch. Content could include defacements, changes to .htaccess, and CGI scripts. nah, dude, look: doco has a very precise editing access point. You can *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, servlet upload, sql injection, cross-site-scripting, and you next favorite attack will NOT work because the system prevents it by design [not saying it cannot happen, but if it does it's a bug, not a faulty design] So long as we can maintain oversight, this is OK. But if someone can spoof the oversight, then I would be concerned. I would *NEVER* propose a system where the users can inject an .htaccess file, even thru approuval. One single oversight mistake and infrastructure@ shuts us down in half a second (if they ever allow the system to run, and I personally wouldn't). The unique and only security concern here is defacement. I am not trying to shoot this idea down. I think it is a good thing to do, and will really help. I really appreciate your concerns and, please, keep in mind that I read and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip stack [also, IMAP over compressed SSH is orders of magnitude faster when you sit in italy and your imap server is in london! ;-)] Anyway, here is a potential attack: Doco sends email to james (localhost). James multiplexes the email to the moderators (vanilla SMTP) the attacker sniffs the continuation-ID replies with the sniffed continuation-ID James calls Doco and restarts the workflow Doco sends back email logging the approuval Potential sniffing places are: 1) right after the doco box (FYI, moof is located at Apple, nagoya at Sun) 2) right before the mail server of the moderator or by people who have enough priviledges on the moderator mail server. The above attack is plausible and it would allow the attacker to get stuff in the repository, but *NOT* to prevent other moderators to see that this content has been approuved. [that would require substantial forging of the output stream... possible as well, but much harder to achieve] The other moderators would see it as a mistake and get there fixing it before the next site update. Keep in mind that there are *two* 12 hour stages, so, even if the attacker attacks right before the first staging (the forrestbot execution), the moderators have 12 hours to understand that something was wrong and login to fix things before the other stage (rsync from minotaur) takes place. I think you proposed to use SMTP over SSL for mail relay, that would reduce the ability of somebody to prevent sniffing the continuation-ID and provide that attack. I do agree it would help reducing the risk, but would all moderator's SMTP server support that? [keep in mind that a sniffer could understand the list of moderators just by watching email outgoing traffic, even if encrypted, by comparing with the list of users on the mail lists] Another solution is to force moderators to digitally sign their email, but this would require a much more intrusive setup. At the end, I don't think anybody would do such an attack since: 1) it can't be proved that it was an attack (we can always say it was a mistake of the moderators), so you can't go around feeling proud of it or impressing friends of the cracker scene [ego is probably 99% of the reasons to deface a web site] 2) the attacker cannot stop others from keeping oversight on what was approuved (doco will send email *after* the moderation to keep oversight of everthing that happened) 3) if we use the lazy consensus moderation method (require 3 accept and no reject), the attack is just as easy, but the chance that the moderator that the attacker would *fake* is offline for 24 hours and cannot yell WTF, I didn't do it at the moderator list is much less So, adding SSL relay wouldn't hurt, but wouldn't help much either since we can't force moderators to have a mail server that accepts that kind of relay (don't even know if mine does!) at least, this is MHO. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Doco
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 6:06 AM To: James Developers List Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; lenya- [EMAIL PROTECTED] On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote: He's not questioning whether it's encrypted. His point is, doco sends an email to an address, and you respond. It gives very little control, even if there is a compromise. AIUI, the proposed solution would allow anyone to edit content, and contribute it as a patch. Content could include defacements, changes to .htaccess, and CGI scripts. nah, dude, look: doco has a very precise editing access point. You can *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, servlet upload, sql injection, cross-site-scripting, and you next favorite attack will NOT work because the system prevents it by design [not saying it cannot happen, but if it does it's a bug, not a faulty design] FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even better?, schema/dtd validation). If it fails, it doesn't even enter the approval process. Perhaps a notification email is sent describing that an invalid submittal was sent. The user is returned an error page saying the post was rejected, in case it was just a mistake. On another note, can images/PDFs/other-binaries be uploaded? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote: nah, dude, look: doco has a very precise editing access point. You can *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, servlet upload, sql injection, cross-site-scripting, and you next favorite attack will NOT work because the system prevents it by design [not saying it cannot happen, but if it does it's a bug, not a faulty design] FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even better?, schema/dtd validation). If it fails, it doesn't even enter the approval process. Absolutely. This wasn't mentioned, but planned. I will do relaxng validation before allowing any xml data into the system. This should be enough for documentation. Perhaps a notification email is sent describing that an invalid submittal was sent. Nah, it would just fail and log the failure. No need to spam further since it might well be a bug in the editing software ;-) [I have experienced a few of them as well] The user is returned an error page saying the post was rejected, in case it was just a mistake. On another note, can images/PDFs/other-binaries be uploaded? Damn, forgot about this! My suggestion would be to process the binary file and determine if it's an image or not. If not, reject it right away. [there should be *NO* need to upload any other binary file ] -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
