On Friday 02 Aug 2013 17:49:30 Martin Nyhus wrote:
> On 08/02/2013 03:47 PM, Matthew Toseland wrote:
> > On Thursday 01 Aug 2013 19:35:47 Martin Nyhus wrote:
> >> I need to go though this is more detail, but some initial
> >> thoughts:
> >
> > Any reason not to forward/CC this to devl?
>
> Nope. Your original email wasn't sent there so I simply didn't think
> about it. I'll send the stuff from your email that I didn't quote
> separately.
>
> >>
> >> On 08/01/2013 02:47 PM, Matthew Toseland wrote:
> >>> 7c9b4d08894f319d0e7022a02d35d96899261958 - not safe, surely? -
> >>> headers can be encoded, can't they? is that implemented in
> >>> Freemail? - this part only deals with body ... but elsewhere
> >>> there must be support for quoted-printable etc in headers. in
> >>> which case this is bogus. Do they use the same charset? It
> >>> would be OK to pass through if the charset is only used for the
> >>> body - but the charset for the headers MUST be known. (and we
> >>> should test this). - it looks like there is support for encoded
> >>> headers. but it seems to be completely separate from support
> >>> for encoded body? SECURITY: quoted-printable etc in headers:
> >>> MUST NOT fallback to raw content!
> >>
> >> That function is only used for displaying things on web pages, so
> >> it is safe assuming the body is 7bit clean (as it should be).
> >> Since we don't actually check the content before displaying or
> >> when receiving we should either:
> >
> > If it's only displayed on a web page, then surely we add it with
> > new HTMLNode("#", string)? If so, it's safe, period.
> >
> > Having said that, my main concern here is header filtering: From,
> > To, etc. Stuff that might be meaningful to clients and cause them
> > to do bad things too. We don't decode before filtering? Should we?
> > Will an encoded From always be rejected?
>
> With the exception of the spoofed From header check, we don't do *any*
> filtering of incoming messages. When clients connect via IMAP they get
> the raw content we store on disk, the IMAP server doesn't decode stuff
> for them. A future filter for incoming messages must of course decode
> messages and generally try to parse what the clients will actually parse.Are there bugs filed for this? > > > > > Okay, so it's just a bit generous in what it accepts in the for() > > loop, and unclear. And over-complicated as a result. There can only > > be space, tab or carriage return, and we only need to writeEncoded > > if it's a carriage return? Also you should rename the buffer, or at > > least document it, to reflect the fact that it's always > > whitespace. > > I don't remember all the details, but e.g. you can't end a line with > whitespace, and you need to be careful about \r\n since it suddenly > has two meanings depending on the context etc. I'll read the RFC again > and > fix/clarify/document the code. Ok. This doesn't block a release though. > >> > >> Not sure I follow here. AssertionError is in java.lang, same > >> thing that is thrown on assert(false). I can't see where anything > >> in tools/ uses TextProtocolTester? > > > > assert(false) is a no-op unless assertions are explicitly enabled > > at run-time with -enableassertions. Which is true for junit but not > > true for tools here? Oh, you don't actually use them in testing > > currently? Ok then. > > Ok my attempt at explaining it was awful. I throw AssertionError in > the cases where my assumptions fail, mostly because I didn't want to > write a lot of error handling code. This has nothing to do with junit > or the unit tests in general. tools/send_receive_message runs a > testcase that sends an email via SMTP using Freemail account 1 then > receives it via IMAP using Freemail account 2. In other words, it > automates sending a real message over the real network for testing, > using the stuff in tools/src/. Ok. IMHO it should use -enableassertions though.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
