[freenet-dev] Merging zidel/next into Freemail v0.2 fred-staging/master

[Martin Nyhus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The stuff from toads original email that I didn't quote:

Freemail_wot:
Merged this, but there are various things to deal with before
releasing it. Some of them serious.

(My version of changelog, I'm happy to keep yours, issues follow after)
Freemail v0.2.4: Reviewed zidel/next and merged into staging/master,
up to 59a5ac628c14a7437db66329343cc0a0d5cb08a7
IMAP:
- - Simplify, refactor parsing of ranges, remove duplicated code.
- - Error handling/checking/messages.
- - Logging.
- - Set Recent flag when copying message.
- - Print [HEADER] in BODY[HEADER] fetch response
- - Lots of tests / lots of work on tests.
- -- Increase protocol timeout to 10s.
- -- Parameterised tests. (Especially for l10n issues)
- -- Reduce duplication.
- - Simplify copy code.
- - Don't try to remove recent flag if not set.
- - Handle single parenthesis around entire search.
General:
- - Charset support: Factor out MailMessage.getBodyReader().
Quoted-printable, base64 support (the message on disk is all 7-bit,
but a charset is specified in the header for the decoded bytes).
- - EncodingOutputStream: Encode messages sent via web interface.
- - Tests.
- -- Add support for tests.extensive flag.
- -- SMTP tests.
- -- Minor refactoring supporting tests.
- -- Various mock classes.
- -- Data for 2 fake mailsites, with addresses etc.
- -- Centralise/dedupe hardcoded identity data in tests, and test
identity creation.
- -- MessageTransportTest.
- -- Logging in unit tests (test.verbose)
- -- Add tools for sending and waiting for messages.
- -- ...
- - Flags fix.
- - Changelog: TODO deal with this.
- - FCPConnection: Always call super.finalize()
- - Various minor cleanups/refactoring.
- - Handle invalid From: header.
- - I18N: Specify date format more exactly.
- - I18N: getBytes("UTF-8") not getBytes(). Don't fallback to default in
MailSite.
- - Checks for impossible cases / future code changes.
- - Javadocs.
- - Indenting.
- - Use JUnit 4.
- - Fix some locale dependant bugs.
- - Fail auth for unknown account name.
- - Minor refactoring/cleanup.
- -- Move thread pools to Freemail from FreemailPlugin (reduce
dependencies), fetch via instance method.
- -- ...
- - SMTP:
- -- Remove dot padding when receiving message.
- -- Check result when sending message on messageSender.
- -- Command formatting.
- - Check for no RTS KSK on mailsite.
- - Don't move MailMessage when storing flags if src == dest
- - Handle WoT errors when matching identities.
- - Error messages.
- - Missing finally{close()}'s.
- - Update freesite link in welcome mail.
- - Logging.
- - Imports.
- - Add copyright headers.
- - Generate message ID's randomly, not based on date.
- - Replace the whole message ID, not just the domain, in
MailHeaderFilter, if the domain is not allowed.
- - Docs: Spec: define acronyms, fix section reference, fix quotes.
- - Add French translation.
Web interface:
- - Add About page with server and account info.
- - Use medium format for date/time.
- - Refactor, return an HTTPResponse (make testing easier) from WebPage's.
- - WoT Fallbacks:
- -- Outbox: Don't show nickname if identity not in WoT.
- - Don't register toadlets in constructor.
- - Close the correct stream after reading message content in
MessageToadlet.
- - Handle messages with no From: header.
Build scripts etc:
- - checkcommit script: document, various improvements.
- - cobertura script (unit test coverage report).
- - checkstyle improvements.
- - test.xml_output -> output junit XML to build-test (e.g. for jenkins)
- - includeantruntime=false
- - new default target, dist no longer depends on unit and checkstyle-auto
- - Add descriptions for clean targets
- - Expand some long lines in build.xml.
- - Only run tests in org/freenetproject/freemail
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJR++NlAAoJEL0Rn1Vb3j1/8MoP/iQpcqiIvoamErB3NvaTV4UL
/YiXmwHL7yxZ156ZuGYLcjpyl1Q1lRSGTuIj0ekSsvDULk2asxiwG05JavF1YpYV
FTeP9jDN9Lu6yEYC8rdFiswtOb3/f2GmBUziVGLv19Ff04oVDocr6jQEi7Yh0RI+
VC/3hJ4cyCugrxRpAuLlbOMceAnUvjhYy02S618/Q0CtQ/wdri+J56xnej2W1Awq
epieX0+x+NAa9EMscCzcWqAtTAxl/e/+5gIw85ZevCU8D2Qrds9tiH+eOuxZc7xm
6mRDxVkZSDhoPWtD7OypOhwMKNfXGiSTOb7NhifszSmFVJMugmYl7o33pqNFA7bS
ESmQxTaoNlLNPTtAIbt4yF2Wjx4zx0ed1YZGyARH5okXzWv7UMHCYV94p1VJpWW+
smB3kb5eHeNx8NJCSnEingIO769hx5OCeRgfiqroqJSZtMcq87u97xG4e+bbX2QJ
HHbR36w55BZQxFxxQsgftasBUVCw8N4PKh+cmStydJQ/EeHuEYzSOmuMwt9Ras0H
dAgkUcKuaoPwRNPt6kAi6jzrhc6GQzbwrcpa6N9Zmjx16T80T+YfyS9K0PEzg6BF
2s4sjal9sYmhmOc5y0GPD4gglM2OxoHPg9WN2BXKi+mk3YBvGxRmTaZfdy0qE8q8
RpxZIlHgJ63A5QfzvPQa
=IfQW
-END PGP SIGNATURE-

[freenet-dev] Merging zidel/next into Freemail v0.2 fred-staging/master

[Martin Nyhus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.

>> 1. Fall back to a mode that displays the raw content, but filters
>> out anything that isn't ASCII printable characters 2. Throw
>> UnsupportedEncodingException and display an error of some kind in
>> the web ui.
>> 
>> So, it might be unsafe at the moment.
> 
> If it's only the web interface then it's safe, although it may look
> garbled. And from the call trace it looks like this is the case.
>> 
>> Headers can be encoded and decoding is implemented in 
>> MailMessage.decodeHeader(). It seems to lack proper test
>> coverage, but it supports both quoted printable[1] (Q) and base64
>> (B) encodings. Charset support depends on the JVM. Encoded
>> headers can have different encodings (even within one header),
>> and it is not related to the body encoding at all. We throw on
>> unknown charsets/encodings in the headers.
>> 
>> [1] Note that quoted printable in the headers doesn't mean the
>> same thing as quoted printable in the body!
>> 
>> 
>>> 40141456bf5457d395b9afac49d1ef3c48c054c5 - i don't understand
>>> how writeBuffer can assert the buffer is only whitespace and
>>> then handle the non-whitespace case? And anyway this is
>>> definitely not always going to be true?
>> 
>> Not 100% sure I understand what is going on (bad sign), so I'll
>> have a look at it later. Looks to me like we only put whitespace
>> into the buffer (which makes sense). Needs fixing anyway, if only
>> to make it easier to understand.
> 
> 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.

>> 
>>> 60aa04c71a778ffd403c032b01b994c2251355d6 - TODO: Fix the
>>> changelog given the versions released weren't as planned. Or
>>> were they close enough? I did the recent releases so I guess I
>>> can deal with this?
>> 
>> W

Re: [freenet-dev] Freemail bugs?

[Martin Nyhus]

On 04/27/2013 01:05 PM, Matthew Toseland wrote:
> On Saturday 27 Apr 2013 01:36:07 Martin Nyhus wrote:
>> On 03/29/2013 12:33 PM, Matthew Toseland wrote:
>>> On Friday 29 Mar 2013 00:07:42 Martin Nyhus wrote:
>>>> I'm not sure how to handle the **SPOOFED** issue properly. For 
>>>> now the easiest thing might be to not check the From header if 
>>>> the sending identity has been whitelisted by the user. Not a
>>>> very user friendly solution, but the only one I can think of
>>>> right now (except dropping the check completely).
>>> 
>>> What does it mean?
>> 
>> When a message is received Freemail checks that the address in the 
>> From header is the same as the address of the identity that we got
>> the message from. If the two don't match, **SPOOFED** is added to
>> the name part of the From header. The problem with mailing lists is
>> obviously that the sender will be the mailing list operator, so the
>> check fails.
>> 
>> Sorry about taking so long to reply to this.
>> 
> I haven't received freemails for a while but in the past I've seen
> SPOOFED on pretty much every message I've received. Maybe that was a
> bug in an old version though...

Might have been. Also, some people had their email clients set up
incorrectly, making it use the wrong address etc. I haven't seen it
lately, probably because most people just use the web mail now.

(Forgot to send this to the list, sorry about the dups toad)



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Freemail bugs?

[Martin Nyhus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/29/2013 12:33 PM, Matthew Toseland wrote:
> On Friday 29 Mar 2013 00:07:42 Martin Nyhus wrote:
>> I'm not sure how to handle the **SPOOFED** issue properly. For
>> now the easiest thing might be to not check the From header if
>> the sending identity has been whitelisted by the user. Not a very
>> user friendly solution, but the only one I can think of right now
>> (except dropping the check completely).
> 
> What does it mean?

When a message is received Freemail checks that the address in the
- From header is the same as the address of the identity that we got the
message from. If the two don't match, **SPOOFED** is added to the name
part of the From header. The problem with mailing lists is obviously
that the sender will be the mailing list operator, so the check fails.


Sorry about taking so long to reply to this.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRex13AAoJEL0Rn1Vb3j1/kgQQAIP6sFDXbXiyhFrUZ1G4lJz9
TMN7c9ubffCI/pNhNsPmBDOEohh2QzFDQvbLHzBmQYiXF934LvLvm4aBg28G/nEN
I8yuz7V5QmQHhAWnarqbZUKbZCASCUt77I9FBR8A+TqDKqlh3p1ojSVxUZsz3qlC
S/pPBFBAcCexalPYKuTzqaKqQclAFfVeiKrh/Z10GpmrgBw70slty9qPpK0/0m/H
ZMNz7KAK/UekiiHEhcjjJ8NTGPuI05UXNADYDasLEYWNNsl0R8t9TMfQiA/mRVTU
2C5oy3Gf+GyPSpe5VzCziz2MxDuXOrYJ1fX8Sds17ESnetfSA/d+DfDxOvimnkRw
FI6DVPIAuEGQEnwjtzzyHVqqUIi2kVa5yCe5VeZc/79zCL3FZ47MEyPpdJEs7i8G
2+UI6Dt8WRJqz9r3+ESjS039AfSx1dOGDPTHI3gruka+Z4iOCdlKkN4oU7KRkRmI
//ehO6JS4IDkiHxufb3M+WTPUsAMR4LcQRyJn26xQLV6PaJIhxfZaYKMRZkwXGur
tUxVlryfv74seIfofN30sM7M2s8FD/lvc3aTePPwigdtG3z8ip7zO1SIioolDPzu
8F5Bv0VKHeYPTINe0rNDkJkAD2aHdcFWThz4fDC0BB7lXTqS2sPAnnhe9eiSjb7M
V9hFlPXM+DJs/GSGmhUB
=j8Gr
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Freemail bugs?

[Martin Nyhus]

On Tue, 26 Mar 2013 15:25:30 + Matthew Toseland wrote:
> This page gives some Freemail bugs related to running a mailing list.

The header issue that is mentioned should be fixed by allowing a few
more headers through the filter. I'm guessing the most important one
here is reply-to since using reply all is mentioned, but the other list
headers should also be safe (more details below).

I'm not sure how to handle the **SPOOFED** issue properly. For now the
easiest thing might be to not check the From header if the sending
identity has been whitelisted by the user. Not a very user friendly
solution, but the only one I can think of right now (except dropping
the check completely).

I'm fairly busy at university at the moment, so I can't really promise
anything, but the header filtering is simple enough that I can probably
get it done in between other stuff. I really should release a new
version anyway, so maybe this is a nice reason to get it done :)


The list related headers I've found so far:

Reply-To:
Should be filtered to only allow Freemail addresses to guard against
configuration mishaps leaking the id of the mailing list operator.
Ideally we would also check this on the recipient side to make sure
email clients can't be tricked into replying outside Freenet.

List-ID:
We can't really do anything about the list name, but the id should
probably be something like name..freemail. Again
the biggest problem is a list configured in a way that leaks the owners
id.

List-Archive
List-Help
List-Owner
List-Post
List-Subscribe
List-Unsubscribe:
Putting http links here won't really work reliably I guess since people
don't need to have their node at 127.0.0.1:, but mailto links that
point to Freemail addresses can at least be allowed through.


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail 0.1.1 and 0.2 released

[Martin Nyhus]

After being in development for nearly a year Freemail 0.2 has been released.
The two main features in 0.2 is the new identity management which uses the Web
of Trust plugin, and a webmail client. This work was mostly done as part of
Google Summer of Code 2011. Due to the identity management changes this
version is incompatible with the earlier releases, but to ease the migration
the two versions can be used at the same time without any issues.

Version 0.1.1 fixes a number of bugs including one potential security issue
that could enable an attacker with access to the Freenet log files to fetch
emails from Freenet after they should have been inaccessible.

Both versions will be available through Freenet after the next update, and from
CHK at 
xXc1H2eh-1OtCoE4Z0-G4~5SfOFpTWa6YWOP~D4PyuA,dKRuAVWFlHd8ZNvFsIJj1Hzzuyoc7EfoVIXYgz-rfsg,AAIC--8/Freemail-0.1.1.jar
CHK at 
S0AnW~5CXyh3pLkzJHbRm5xj8kf26GyLcT3Zuf1UAsU,pt-TGV39s1ucWNTkZKMdo1dQyaxzaUsSjXlYtBAqfvc,AAIC--8/Freemail-0.2.jar

I am very interested in feedback about the reliability of Freemail, any bugs I
have missed and performance problems. This can be reported through the mailing
list, the bug tracker and on Freenet.


Detailed changelog for 0.1.1 (also included in 0.2):
  o Security fixes:
- Log message fetch and insert keys at debug instead of normal/error. If a
  collision occurred the new slot would be logged at error, which
  would break the forward secrecy of the slot system until the log was
  deleted. This would enable an attacker with access to the log files to
  retrieve messages from Freenet.

  o Bugfixes:
- Folders deleted using a mail client are now deleted properly
- Fixes a crash that could occur if a mail client connected while Freemail
  was shutting down
- The startup message now shows the correct licence (GPL)
- Fixes a bug where certain email addresses would cause received messages to
  be empty
- Fixes a race condition which could lead to Freemail hanging
- Don't delete CC headers from a message before sending
- Always print a log message when Freemail isn't connected to the node
- IMAP: Remove extra space that was printed in a fetch response without a 
range
- IMAP: Fix error message when the end of a range was invalid
- IMAP: Handle strange sequence number ranges
- IMAP: Remove \* from permanent flags since they were not stored
- IMAP: Fix append with two or more flags
- IMAP: Reply with error if the append length couldn't be parsed
- Fix various locking issues
- Don't log the recently failed fetch result as an error

  o Improvements:
- Improve the explanations on the create account page
- Only resend the RTS once per two days instead of once per message in the
  outbox per two days, reducing resource usage for unacked messages
- Send messages in the order they will be received, improving performance
  when sending a large amount of messages
- Alternate between sending and receiving, stopping sending/receiving a 
large
  number of messages from blocking other operations

  o Build improvements:
- Compile for Java 1.6
- Include git describe output in version
- Enable warnings when building
- Make Ant and Eclipse output files to the same location (build/)

  o Code changes:
- Add unit tests for various classes (mostly IMAP)
- Improve errors returned/thrown by HighLevelFCPClient
- Add type parameters to all code
- Add missing @Override annotations
- Throw AssertionError in some cases that should be impossible
- Use constants for config file keys
- Respond to interrupts in the FCP code
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Freemail 0.1.1 and 0.2 released

[Martin Nyhus]

After being in development for nearly a year Freemail 0.2 has been released.
The two main features in 0.2 is the new identity management which uses the Web
of Trust plugin, and a webmail client. This work was mostly done as part of
Google Summer of Code 2011. Due to the identity management changes this
version is incompatible with the earlier releases, but to ease the migration
the two versions can be used at the same time without any issues.

Version 0.1.1 fixes a number of bugs including one potential security issue
that could enable an attacker with access to the Freenet log files to fetch
emails from Freenet after they should have been inaccessible.

Both versions will be available through Freenet after the next update, and from
CHK@xXc1H2eh-1OtCoE4Z0-G4~5SfOFpTWa6YWOP~D4PyuA,dKRuAVWFlHd8ZNvFsIJj1Hzzuyoc7EfoVIXYgz-rfsg,AAIC--8/Freemail-0.1.1.jar
CHK@S0AnW~5CXyh3pLkzJHbRm5xj8kf26GyLcT3Zuf1UAsU,pt-TGV39s1ucWNTkZKMdo1dQyaxzaUsSjXlYtBAqfvc,AAIC--8/Freemail-0.2.jar

I am very interested in feedback about the reliability of Freemail, any bugs I
have missed and performance problems. This can be reported through the mailing
list, the bug tracker and on Freenet.


Detailed changelog for 0.1.1 (also included in 0.2):
  o Security fixes:
- Log message fetch and insert keys at debug instead of normal/error. If a
  collision occurred the new slot would be logged at error, which
  would break the forward secrecy of the slot system until the log was
  deleted. This would enable an attacker with access to the log files to
  retrieve messages from Freenet.

  o Bugfixes:
- Folders deleted using a mail client are now deleted properly
- Fixes a crash that could occur if a mail client connected while Freemail
  was shutting down
- The startup message now shows the correct licence (GPL)
- Fixes a bug where certain email addresses would cause received messages to
  be empty
- Fixes a race condition which could lead to Freemail hanging
- Don't delete CC headers from a message before sending
- Always print a log message when Freemail isn't connected to the node
- IMAP: Remove extra space that was printed in a fetch response without a 
range
- IMAP: Fix error message when the end of a range was invalid
- IMAP: Handle strange sequence number ranges
- IMAP: Remove \* from permanent flags since they were not stored
- IMAP: Fix append with two or more flags
- IMAP: Reply with error if the append length couldn't be parsed
- Fix various locking issues
- Don't log the recently failed fetch result as an error

  o Improvements:
- Improve the explanations on the create account page
- Only resend the RTS once per two days instead of once per message in the
  outbox per two days, reducing resource usage for unacked messages
- Send messages in the order they will be received, improving performance
  when sending a large amount of messages
- Alternate between sending and receiving, stopping sending/receiving a 
large
  number of messages from blocking other operations

  o Build improvements:
- Compile for Java 1.6
- Include git describe output in version
- Enable warnings when building
- Make Ant and Eclipse output files to the same location (build/)

  o Code changes:
- Add unit tests for various classes (mostly IMAP)
- Improve errors returned/thrown by HighLevelFCPClient
- Add type parameters to all code
- Add missing @Override annotations
- Throw AssertionError in some cases that should be impossible
- Use constants for config file keys
- Respond to interrupts in the FCP code


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

[freenet-dev] Logging subsystem rewrite

[Martin Nyhus]

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much every 
single plugin out there, so you really should rewrite Logger to call the new 
methods in your new logger class.

I won't say much about the code since you say you aren't finished, but please 
follow the code style of the rest of the code base.

Also, I'm pretty sure you don't want to close the new stream here[0]. And the 
locking when you update out isn't sufficient for visibility (either that or it 
isn't clear enough why it works IMHO).

[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49

Re: [freenet-dev] Logging subsystem rewrite

[Martin Nyhus]

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much every 
single plugin out there, so you really should rewrite Logger to call the new 
methods in your new logger class.

I won't say much about the code since you say you aren't finished, but please 
follow the code style of the rest of the code base.

Also, I'm pretty sure you don't want to close the new stream here[0]. And the 
locking when you update out isn't sufficient for visibility (either that or it 
isn't clear enough why it works IMHO).

[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Coding standards

[Martin Nyhus]

On Tue, 20 Mar 2012 12:07:06 +0100
Nicolas Hernandez  wrote:
> Could it be possible to have a checktsyle file ?

I've played around with Checkstyle a bit and it looks like it could be
configured to detect quite a lot of stuff. You can find what I've done
here[0] if you are interested (config, Ant target and a script for
checking commits). The main problem I see is that there is a lot of
code that should be fixed, so checks have to be added slowly so people
won't just ignore it.

Having at least a subset of the checks being run on each build would be
nice, even if it would only catch simple things.

Disclamer: the full config currently in my tree produces 104k warnings
and is probably poorly suited to Freenet, so some tweaking is needed :)


[0] https://github.com/zidel/fred-staging/tree/checkstyle

Re: [freenet-dev] Coding standards

[Martin Nyhus]

On Tue, 20 Mar 2012 12:07:06 +0100
Nicolas Hernandez  wrote:
> Could it be possible to have a checktsyle file ?

I've played around with Checkstyle a bit and it looks like it could be
configured to detect quite a lot of stuff. You can find what I've done
here[0] if you are interested (config, Ant target and a script for
checking commits). The main problem I see is that there is a lot of
code that should be fixed, so checks have to be added slowly so people
won't just ignore it.

Having at least a subset of the checks being run on each build would be
nice, even if it would only catch simple things.

Disclamer: the full config currently in my tree produces 104k warnings
and is probably poorly suited to Freenet, so some tweaking is needed :)


[0] https://github.com/zidel/fred-staging/tree/checkstyle
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging in Fred

[Martin Nyhus]

On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
> How often does what happen?

Crashes that cause the log buffer to be lost before it is written to disk and 
whatever else you had in mind when you wrote this:

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be miles ahead from the last message
> written to disk, and suddenly you have no idea where to look for the
> bug. Shotgun debugging indeed.

Re: [freenet-dev] Logging in Fred

[Martin Nyhus]

On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
> How often does what happen?

Crashes that cause the log buffer to be lost before it is written to disk and 
whatever else you had in mind when you wrote this:

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be miles ahead from the last message
> written to disk, and suddenly you have no idea where to look for the
> bug. Shotgun debugging indeed.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging in Fred

[Martin Nyhus]

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be miles ahead from the last message
> written to disk, and suddenly you have no idea where to look for the
> bug. Shotgun debugging indeed.

How often does this actually happen? Considering the performance penalty it 
has to fix a very real problem IMHO, especially since having logging change 
how the code behaves in such a dramatic way will make debugging anything that 
depends on timing that much harder.

Re: [freenet-dev] Logging in Fred

[Martin Nyhus]

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be miles ahead from the last message
> written to disk, and suddenly you have no idea where to look for the
> bug. Shotgun debugging indeed.

How often does this actually happen? Considering the performance penalty it 
has to fix a very real problem IMHO, especially since having logging change 
how the code behaves in such a dramatic way will make debugging anything that 
depends on timing that much harder.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail status update

[Martin Nyhus]

On Wed, 6 Jul 2011 21:10:56 +0200 xor  wrote:
> Is there any problem with 2 channels besides the inefficiency?
> Can't we just ignore the problem given that it is very unlikely to happen?
> 
> The channels will have a finite timeout of some days or so anyway according 
> to 
> what we discussed in the initial meeting, right? So the situation will fix 
> itself after some time if it ever happens.

Seems I've been thinking inside that infamous box :/ Having 2 channels
is perfectly fine, so that solves it. Thanks :)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

Re: [freenet-dev] Freemail status update

[Martin Nyhus]

On Wed, 6 Jul 2011 21:10:56 +0200 xor  wrote:
> Is there any problem with 2 channels besides the inefficiency?
> Can't we just ignore the problem given that it is very unlikely to happen?
> 
> The channels will have a finite timeout of some days or so anyway according 
> to 
> what we discussed in the initial meeting, right? So the situation will fix 
> itself after some time if it ever happens.

Seems I've been thinking inside that infamous box :/ Having 2 channels
is perfectly fine, so that solves it. Thanks :)


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail status update

[Martin Nyhus]

Sending emails using the new web interface now works using all the new
parts, except it is still using the old RTS code. I still haven't
updated the SMTP code so it doesn't work at the moment, but fixing that
shouldn't be a lot of work. There is some work left before everything
else works as it should, but I'm quite confident that I'll only be
working on the UI stuff after midterm (except the RTS changes and a few
bugs).

There is still a problem with the channels that needs fixing. If
both Alice and Bob sends messages to each other at the same time they
will end up using two different channels, so we need to resolve that
conflict somehow. My first though was something like this:

  The receiver of an RTS first checks if it has a keypair for the
  channel already. If not there is no conflict to be resolved, so the
  values in the RTS are used for the new channel with the sender.
  If the recipient already has a keypair the two identity IDs are
  compared and the keypair of the identity with the lowest ID is used.
  The identity with the lowest ID must also resend the RTS in case Bob
  has deleted a previous channel he had with Alice and sends a new
  message to her (Alice has the lowest ID).


However forcing one side to resend the RTS means having the user solve
another captcha, in some cases just to receive messages, which is
something I'd like to avoid. Any thoughts or other options?

Some cases to consider:
 * Alice sends a message to Bob (no previous channel)
 * Both Alice and Bob tries to open a new channel at the same time
 * Alice sends a message to Bob, who knows of a previous channel that
   Alice has deleted
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

[freenet-dev] Freemail status update

[Martin Nyhus]

Sending emails using the new web interface now works using all the new
parts, except it is still using the old RTS code. I still haven't
updated the SMTP code so it doesn't work at the moment, but fixing that
shouldn't be a lot of work. There is some work left before everything
else works as it should, but I'm quite confident that I'll only be
working on the UI stuff after midterm (except the RTS changes and a few
bugs).

There is still a problem with the channels that needs fixing. If
both Alice and Bob sends messages to each other at the same time they
will end up using two different channels, so we need to resolve that
conflict somehow. My first though was something like this:

  The receiver of an RTS first checks if it has a keypair for the
  channel already. If not there is no conflict to be resolved, so the
  values in the RTS are used for the new channel with the sender.
  If the recipient already has a keypair the two identity IDs are
  compared and the keypair of the identity with the lowest ID is used.
  The identity with the lowest ID must also resend the RTS in case Bob
  has deleted a previous channel he had with Alice and sends a new
  message to her (Alice has the lowest ID).


However forcing one side to resend the RTS means having the user solve
another captcha, in some cases just to receive messages, which is
something I'd like to avoid. Any thoughts or other options?

Some cases to consider:
 * Alice sends a message to Bob (no previous channel)
 * Both Alice and Bob tries to open a new channel at the same time
 * Alice sends a message to Bob, who knows of a previous channel that
   Alice has deleted


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail licensing

[Martin Nyhus]

I've made an attempt at relicensing the code:
https://github.com/zidel/plugin-Freemail-staging/tree/relicense

It should be quite simple even though some of the commits are quite
large. Unfortunately that also meant reverting esr's change since I
haven't heard anything from him, so I wrote a replacement (still needs
some work, especially the part about the short address):
https://github.com/zidel/plugin-Freemail-staging/commits/accountForm
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

Re: [freenet-dev] Freemail licensing

[Martin Nyhus]

I've made an attempt at relicensing the code:
https://github.com/zidel/plugin-Freemail-staging/tree/relicense

It should be quite simple even though some of the commits are quite
large. Unfortunately that also meant reverting esr's change since I
haven't heard anything from him, so I wrote a replacement (still needs
some work, especially the part about the short address):
https://github.com/zidel/plugin-Freemail-staging/commits/accountForm


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail licensing

[Martin Nyhus]

On Thu, 28 Apr 2011 19:13:40 +0200 Alexander Lehmann wrote:
> I am ok with using GLPv2+ as well.

As far as I know that takes care of everyone but esr and his/her commit
only touched the 'Add account' page which should probably be rewritten
anyway. I haven't got the time to take care of this right now because
of an exam, but if no one else has done it by Thursday I can probably
do it then.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 

Re: [freenet-dev] Freemail licensing

[Martin Nyhus]

On Thu, 28 Apr 2011 19:13:40 +0200 Alexander Lehmann wrote:
> I am ok with using GLPv2+ as well.

As far as I know that takes care of everyone but esr and his/her commit
only touched the 'Add account' page which should probably be rewritten
anyway. I haven't got the time to take care of this right now because
of an exam, but if no one else has done it by Thursday I can probably
do it then.


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail licensing

[Martin Nyhus]

On Tue, 26 Apr 2011 21:33:00 +0200 Alexander Lehmann wrote:
> you can put the Logger class under the same license as the rest of 
> Freemail (i.e. lgpl 2.1+), I think I intended to do that or have Dave do 
> it, but since I stopped working on Freemail a while back due to time 
> constraints, I never actually did.
> 
> I looked up the commit log messages, I believe I didn't use any code 
> (except the api from freenet Logger, but that isn't used directly either)

Great! How do you feel about the re-licensing to GPLv2 or later that
Dave suggested? I think you have gotten the email already, but I've
included it below just in case:



Absolutely, I'm happy for those files to be marked up as LGPL v2.1+ - I
released the whole of Freemail under the LGPL so I'm certain its safe
to assume the same applies to those source files, but thanks for asking
nonetheless - I understand how thorny these issues can get. For the
avoidance of doubt, I'm happy for these files to be released under LGPL
v2.1 or later.

As for the code from Freenet, at the time they were imported, Freenet
was under the LGPL (which was why Freemail was too) - it changed on the
3rd of September 2006
(https://github.com/freenet/fred-official/commit/65e0628e9a9477bd661025dd70bce364486db5b2
- although the commit message here implies that it was GPL before, but
I'm not sure what the source for that is). I think it would be very
strange to have a couple of files in Freemail released as GPL when the
rest is LGPL, and would slightly complicate what license the project as
a whole is released under. Given that the rest of Freenet is GPL, the
solution I would be inclined towards would be to stay in keeping with
Freenet's license and re-license Freemail as GPL - in this case there
shouldn't be many original authors to contact. The other option would
be to keep the whole lot as LGPL assuming we can clear up the ambiguity
of what license the Freenet files were when they were copied in the
first place.

Any thoughts on this, anyone?



Dave

Re: [freenet-dev] Freemail licensing

[Martin Nyhus]

On Tue, 26 Apr 2011 21:33:00 +0200 Alexander Lehmann wrote:
> you can put the Logger class under the same license as the rest of 
> Freemail (i.e. lgpl 2.1+), I think I intended to do that or have Dave do 
> it, but since I stopped working on Freemail a while back due to time 
> constraints, I never actually did.
> 
> I looked up the commit log messages, I believe I didn't use any code 
> (except the api from freenet Logger, but that isn't used directly either)

Great! How do you feel about the re-licensing to GPLv2 or later that
Dave suggested? I think you have gotten the email already, but I've
included it below just in case:



Absolutely, I'm happy for those files to be marked up as LGPL v2.1+ - I
released the whole of Freemail under the LGPL so I'm certain its safe
to assume the same applies to those source files, but thanks for asking
nonetheless - I understand how thorny these issues can get. For the
avoidance of doubt, I'm happy for these files to be released under LGPL
v2.1 or later.

As for the code from Freenet, at the time they were imported, Freenet
was under the LGPL (which was why Freemail was too) - it changed on the
3rd of September 2006
(https://github.com/freenet/fred-official/commit/65e0628e9a9477bd661025dd70bce364486db5b2
- although the commit message here implies that it was GPL before, but
I'm not sure what the source for that is). I think it would be very
strange to have a couple of files in Freemail released as GPL when the
rest is LGPL, and would slightly complicate what license the project as
a whole is released under. Given that the rest of Freenet is GPL, the
solution I would be inclined towards would be to stay in keeping with
Freenet's license and re-license Freemail as GPL - in this case there
shouldn't be many original authors to contact. The other option would
be to keep the whole lot as LGPL assuming we can clear up the ambiguity
of what license the Freenet files were when they were copied in the
first place.

Any thoughts on this, anyone?



Dave
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Freemail licensing

[Martin Nyhus]

On Sat, 16 Apr 2011 16:57:12 +0100 David Baker wrote:
> On 16 Apr 2011, at 16:52, Matthew Toseland wrote:
> > On Saturday 16 Apr 2011 15:04:06 David Baker wrote:
> >>> Hi,
> >>> I've been going over the Freemail code, and I noticed that some of the
> >>> files lack the GPL header they should have. I assume they should have
> >>> one since Freemail as a whole is GPL'ed, but I still need your
> >>> permission in order to add them, so I made a list of files that you
> >>> have touched and that lack the proper header:
> >>> 
> >>> These don't appear to use code from anywhere else, so they should
> >>> probably be LGPLv2.1+ like the rest of Freemail:
> >>> src/freemail/utils/Logger.java
> >>> src/freemail/ServerListener.java
> >>> src/freemail/FreemailAccount.java
> >>> src/freemail/ServerHandler.java
> >>> src/freemail/fcp/ConnectionTerminatedException.java
> >>> 
> >>> These two use code from Freenet that was licenced as GPLv2+, so they
> >>> need to inherit that license:
> >>> src/freemail/support/io/LineReadingInputStream.java
> >>> src/freemail/fcp/FCPFetchException.java
> >>> 
> >>> If you could take the time to send a message to devl at freenetproject.org
> >>> stating what license you want to release your changes under that would
> >>> be very helpful.
> >>> 
> >>>   Martin Nyhus
> >> 
> >> Hi Martin / All,
> >> 
> >> Apologies for the slight delay in replying - I'm just back from holiday.
> >> 
> >> Absolutely, I'm happy for those files to be marked up as LGPL v2.1+ - I 
> >> released the whole of Freemail under the LGPL so I'm certain its safe to 
> >> assume the same applies to those source files, but thanks for asking 
> >> nonetheless - I understand how thorny these issues can get. For the 
> >> avoidance of doubt, I'm happy for these files to be released under LGPL 
> >> v2.1 or later.
> >> 
> >> As for the code from Freenet, at the time they were imported, Freenet was 
> >> under the LGPL (which was why Freemail was too) - it changed on the 3rd of 
> >> September 2006 
> >> (https://github.com/freenet/fred-official/commit/65e0628e9a9477bd661025dd70bce364486db5b2
> >>  - although the commit message here implies that it was GPL before, but 
> >> I'm not sure what the source for that is). I think it would be very 
> >> strange to have a couple of files in Freemail released as GPL when the 
> >> rest is LGPL, and would slightly complicate what license the project as a 
> >> whole is released under. Given that the rest of Freenet is GPL, the 
> >> solution I would be inclined towards would be to stay in keeping with 
> >> Freenet's license and re-license Freemail as GPL - in this case there 
> >> shouldn't be many original authors to contact. The other option would be 
> >> to keep the whole lot as LGPL assuming we can clear up the ambiguity of 
> >> what license the Freenet files were when they were copied in the first 
> >> place.
> > 
> > I vote for GPL2+, I'd be happy with anything GPL3 compatible though (GPL2 
> > isn't ASL2 compatible).
> 
> Okay, will see what Martin / others think but that sounds fair to me.

I'm fine with GPL2+ as well. Based on a quick look at Git that leaves
alexlehm, esr and Daniel Cheng.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20110416/a7275362/attachment.pgp>

Re: [freenet-dev] Freemail licensing

[Martin Nyhus]

On Sat, 16 Apr 2011 16:57:12 +0100 David Baker wrote:
> On 16 Apr 2011, at 16:52, Matthew Toseland wrote:
> > On Saturday 16 Apr 2011 15:04:06 David Baker wrote:
> >>> Hi,
> >>> I've been going over the Freemail code, and I noticed that some of the
> >>> files lack the GPL header they should have. I assume they should have
> >>> one since Freemail as a whole is GPL'ed, but I still need your
> >>> permission in order to add them, so I made a list of files that you
> >>> have touched and that lack the proper header:
> >>> 
> >>> These don't appear to use code from anywhere else, so they should
> >>> probably be LGPLv2.1+ like the rest of Freemail:
> >>> src/freemail/utils/Logger.java
> >>> src/freemail/ServerListener.java
> >>> src/freemail/FreemailAccount.java
> >>> src/freemail/ServerHandler.java
> >>> src/freemail/fcp/ConnectionTerminatedException.java
> >>> 
> >>> These two use code from Freenet that was licenced as GPLv2+, so they
> >>> need to inherit that license:
> >>> src/freemail/support/io/LineReadingInputStream.java
> >>> src/freemail/fcp/FCPFetchException.java
> >>> 
> >>> If you could take the time to send a message to devl@freenetproject.org
> >>> stating what license you want to release your changes under that would
> >>> be very helpful.
> >>> 
> >>>   Martin Nyhus
> >> 
> >> Hi Martin / All,
> >> 
> >> Apologies for the slight delay in replying - I'm just back from holiday.
> >> 
> >> Absolutely, I'm happy for those files to be marked up as LGPL v2.1+ - I 
> >> released the whole of Freemail under the LGPL so I'm certain its safe to 
> >> assume the same applies to those source files, but thanks for asking 
> >> nonetheless - I understand how thorny these issues can get. For the 
> >> avoidance of doubt, I'm happy for these files to be released under LGPL 
> >> v2.1 or later.
> >> 
> >> As for the code from Freenet, at the time they were imported, Freenet was 
> >> under the LGPL (which was why Freemail was too) - it changed on the 3rd of 
> >> September 2006 
> >> (https://github.com/freenet/fred-official/commit/65e0628e9a9477bd661025dd70bce364486db5b2
> >>  - although the commit message here implies that it was GPL before, but 
> >> I'm not sure what the source for that is). I think it would be very 
> >> strange to have a couple of files in Freemail released as GPL when the 
> >> rest is LGPL, and would slightly complicate what license the project as a 
> >> whole is released under. Given that the rest of Freenet is GPL, the 
> >> solution I would be inclined towards would be to stay in keeping with 
> >> Freenet's license and re-license Freemail as GPL - in this case there 
> >> shouldn't be many original authors to contact. The other option would be 
> >> to keep the whole lot as LGPL assuming we can clear up the ambiguity of 
> >> what license the Freenet files were when they were copied in the first 
> >> place.
> > 
> > I vote for GPL2+, I'd be happy with anything GPL3 compatible though (GPL2 
> > isn't ASL2 compatible).
> 
> Okay, will see what Martin / others think but that sounds fair to me.

I'm fine with GPL2+ as well. Based on a quick look at Git that leaves
alexlehm, esr and Daniel Cheng.


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Merging zidel's new packet format branch

[Martin Nyhus]

On Friday 24. December 2010 16:26:59 Matthew Toseland wrote:
> On Tuesday 21 December 2010 23:18:50 Martin Nyhus wrote:
> > At the moment I'm not using the first bit of the sequence number for some
> > reason (that I can't remember).
> Worth checking but not critical.

I've already done it, but the extra complexity might not be worth it. Feel 
free to ask me to revert it if you agree.

> > There is also the problem of message ids
> > wrapping within the watchlist window, but I don't think it can happen
> > with the current code unless the sender actively makes it happen.
> Right. Well, if it's not going to happen naturally, it's an exploit, but
> AFAICS it's not a useful exploit, right?

I thought about this over the weekend and I've convinced myself that it can't 
happen unless the sender uses only every ~1000th message id, and I can't see 
that happening without changing the code. If it were to happen it would be 
possible to replace parts of a message with the same parts of an earlier 
message with the same id.

Some numbers:

Assuming we can send 1400 messages in a packet (way too high...) we can send 
1.4M messages in the window, which isn't anywhere near the number needed for 
wrapping the ids (2^28 or ~268M). In practice I'd say the average number of 
messages per packet is roughly 10.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20101227/ec903bb2/attachment.pgp>

Re: [freenet-dev] Merging zidel's new packet format branch

[Martin Nyhus]

On Friday 24. December 2010 16:26:59 Matthew Toseland wrote:
> On Tuesday 21 December 2010 23:18:50 Martin Nyhus wrote:
> > At the moment I'm not using the first bit of the sequence number for some
> > reason (that I can't remember).
> Worth checking but not critical.

I've already done it, but the extra complexity might not be worth it. Feel 
free to ask me to revert it if you agree.

> > There is also the problem of message ids
> > wrapping within the watchlist window, but I don't think it can happen
> > with the current code unless the sender actively makes it happen.
> Right. Well, if it's not going to happen naturally, it's an exploit, but
> AFAICS it's not a useful exploit, right?

I thought about this over the weekend and I've convinced myself that it can't 
happen unless the sender uses only every ~1000th message id, and I can't see 
that happening without changing the code. If it were to happen it would be 
possible to replace parts of a message with the same parts of an earlier 
message with the same id.

Some numbers:

Assuming we can send 1400 messages in a packet (way too high...) we can send 
1.4M messages in the window, which isn't anywhere near the number needed for 
wrapping the ids (2^28 or ~268M). In practice I'd say the average number of 
messages per packet is roughly 10.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Merging zidel's new packet format branch

[Martin Nyhus]

On Tuesday 21. December 2010 20:26:11 Matthew Toseland wrote:
> Zidel, what's left in your view?

At the moment I'm not using the first bit of the sequence number for some 
reason (that I can't remember). There is also the problem of message ids 
wrapping within the watchlist window, but I don't think it can happen with the 
current code unless the sender actively makes it happen.

I'll try to look through all of your earlier reviews to see if I've forgotten 
something, but I think those are the only issues that need to be resolved 
before merging.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Merging zidel's new packet format branch

[Martin Nyhus]

On Tuesday 21. December 2010 20:26:11 Matthew Toseland wrote:
> Zidel, what's left in your view?

At the moment I'm not using the first bit of the sequence number for some 
reason (that I can't remember). There is also the problem of message ids 
wrapping within the watchlist window, but I don't think it can happen with the 
current code unless the sender actively makes it happen.

I'll try to look through all of your earlier reviews to see if I've forgotten 
something, but I think those are the only issues that need to be resolved 
before merging.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Packet sequence numbers must not wrap!

[Martin Nyhus]

On Friday 19. November 2010 22:04:25 Matthew Toseland wrote:
> Ok. However IMHO packet numbers need to be per-key, and it is possible for
> two keys to temporarily be live at once (at least it should be,
> implementing it that way in old FNP fixed some largish issues).

Good point. 72768a0 is a quick fix, but it won't work if a tracker we've used 
before becomes the current tracker again.

For example, if tracker A is the previous tracker, could it happen that A is 
promoted to the current tracker? It looks like it could happen in 
maybeSwapTrackers(), but both callers replace previousTracker first so it 
should be fine right?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Packet sequence numbers must not wrap!

[Martin Nyhus]

On Friday 19. November 2010 22:04:25 Matthew Toseland wrote:
> Ok. However IMHO packet numbers need to be per-key, and it is possible for
> two keys to temporarily be live at once (at least it should be,
> implementing it that way in old FNP fixed some largish issues).

Good point. 72768a0 is a quick fix, but it won't work if a tracker we've used 
before becomes the current tracker again.

For example, if tracker A is the previous tracker, could it happen that A is 
promoted to the current tracker? It looks like it could happen in 
maybeSwapTrackers(), but both callers replace previousTracker first so it 
should be fine right?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] More work on packet format branch

[Martin Nyhus]

On Tuesday 9. November 2010 14:20:19 Matthew Toseland wrote:
> > > 7b2a66a803688e1be8d70f3e8eb3854f7b900242
> > > - You should add and subtract the full overhead. Is HMAC_LENGTH the
> > > totality of the overhead apart from what's already accounted for in
> > > packet.getLength()? (I.e. the sequence number?) Looks like it is ...
> > HMAC_LENGTH is the length of the HMAC.
> IMHO the packet length calculations for padding should be based on the full
> length. Are they?

It is based on the length of the packet (HMAC, sequence number etc.), not 
including UDP headers, which sounds right to me since that is what 
maxPacketSize covers.

> Why would paddedLen *ever* be larger than maxPacketSize? I thought one of
> the purposes of this was to enable us to generate packets of almost any
> size? Granted it can be in old FNP, which is the origin of that code.

My bad, looks like it can't happen.

> > > e2b0b8ee4e54b95839facdc66c781663e9f5626d
> > > - Did you double check that this is all either exclusively your own
> > > code or drawn from files that have the GPL2+ headers already?
> Actually some of it is copied from various parts of our code, you should
> check that those files already have GPL2+ headers (I think they do..)

I looked over it again and both IncomingPacketFilterImpl and NewPacketFormat 
has code from FNPPacketMangler which is GPL2+. The only other thing I can 
remember copying is ReceivedPacketNumbers into SparseBitmap, but I didn't add 
any headers to it.

> Hmmm. Calling your allocation method getSequenceNumber() is confusing,
> especially when packet has a similar method which is just a getter. It
> would help to change it to allocateSequenceNumber().

Done (d4fe2f5)

> > > "it" here means the window I guess. Should it be updated incrementally
> > > i.e. on every packet?
> > I don't see why it shouldn't, as only the sequence numbers that are
> > outside the window are updated.
> 
> IIRC the window is updated every time we reach half way into it?

Half the window is behind the highest received sequence number, and I guess it 
isn't explained very well... The window is moved every time we get a packet 
with a higher sequence number.

> > > > 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> > > > - Any particular reason for always starting from 0 on new format?
> > Done (807ea29)
> This starts with the same random sequence number in each direction afaics?
> That could be confusing.

I changed it in 71325e2 to use different numbers in each direction, so it 
should be clearer that they are independent.

> We should probably restrict the random range to not be too close to
> rollover. Especially as we need to be absolutely sure we rekey before we
> rollover, if necessary shutting down the connection to avoid sending two
> packets encrypted with the same sequence number.

The rollover back to 0 isn't a problem, the problem is reusing sequence number 
(dealt with in another patch), so starting close to the maximum value 
shouldn't matter.

> Also, we had originally planned to have a separate cipher key in each
> direction. This should be easy to implement now, and rather harder later
> on.

Done in 71325e2..8e63721
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] More work on packet format branch

[Martin Nyhus]

On Tuesday 9. November 2010 14:20:19 Matthew Toseland wrote:
> > > 7b2a66a803688e1be8d70f3e8eb3854f7b900242
> > > - You should add and subtract the full overhead. Is HMAC_LENGTH the
> > > totality of the overhead apart from what's already accounted for in
> > > packet.getLength()? (I.e. the sequence number?) Looks like it is ...
> > HMAC_LENGTH is the length of the HMAC.
> IMHO the packet length calculations for padding should be based on the full
> length. Are they?

It is based on the length of the packet (HMAC, sequence number etc.), not 
including UDP headers, which sounds right to me since that is what 
maxPacketSize covers.

> Why would paddedLen *ever* be larger than maxPacketSize? I thought one of
> the purposes of this was to enable us to generate packets of almost any
> size? Granted it can be in old FNP, which is the origin of that code.

My bad, looks like it can't happen.

> > > e2b0b8ee4e54b95839facdc66c781663e9f5626d
> > > - Did you double check that this is all either exclusively your own
> > > code or drawn from files that have the GPL2+ headers already?
> Actually some of it is copied from various parts of our code, you should
> check that those files already have GPL2+ headers (I think they do..)

I looked over it again and both IncomingPacketFilterImpl and NewPacketFormat 
has code from FNPPacketMangler which is GPL2+. The only other thing I can 
remember copying is ReceivedPacketNumbers into SparseBitmap, but I didn't add 
any headers to it.

> Hmmm. Calling your allocation method getSequenceNumber() is confusing,
> especially when packet has a similar method which is just a getter. It
> would help to change it to allocateSequenceNumber().

Done (d4fe2f5)

> > > "it" here means the window I guess. Should it be updated incrementally
> > > i.e. on every packet?
> > I don't see why it shouldn't, as only the sequence numbers that are
> > outside the window are updated.
> 
> IIRC the window is updated every time we reach half way into it?

Half the window is behind the highest received sequence number, and I guess it 
isn't explained very well... The window is moved every time we get a packet 
with a higher sequence number.

> > > > 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> > > > - Any particular reason for always starting from 0 on new format?
> > Done (807ea29)
> This starts with the same random sequence number in each direction afaics?
> That could be confusing.

I changed it in 71325e2 to use different numbers in each direction, so it 
should be clearer that they are independent.

> We should probably restrict the random range to not be too close to
> rollover. Especially as we need to be absolutely sure we rekey before we
> rollover, if necessary shutting down the connection to avoid sending two
> packets encrypted with the same sequence number.

The rollover back to 0 isn't a problem, the problem is reusing sequence number 
(dealt with in another patch), so starting close to the maximum value 
shouldn't matter.

> Also, we had originally planned to have a separate cipher key in each
> direction. This should be easy to implement now, and rather harder later
> on.

Done in 71325e2..8e63721


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Packet sequence numbers must not wrap!

[Martin Nyhus]

On Tuesday 9. November 2010 19:49:39 Matthew Toseland wrote:
> What are your thoughts on this issue? IMHO the moment we encrypt two
> packets with the same key and the same sequence number game over. We need
> to be absolutely sure we will rekey before that happens, and if the rekey
> fails we will disconnect. The other option - using a very long counter -
> is interesting, possibly in combination. What does the packetFormat branch
> do now?

I agree that we can't let the sequence numbers wrap since we use them for 
crypto. c73cce16..026a2845 implements the first solution you mentioned, 
refusing to send packets until after a new rekey (and starts one when needed 
of course). b2ca18a8 improves it sligthly by starting the rekey 100 packets 
before we would stop sending (this number should probably be higher, or based 
on how fast we send packets).

As for the message ids, we are safe for now because the window is so small, 
but I'll try to add some more checks just to make sure.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Packet sequence numbers must not wrap!

[Martin Nyhus]

On Tuesday 9. November 2010 19:49:39 Matthew Toseland wrote:
> What are your thoughts on this issue? IMHO the moment we encrypt two
> packets with the same key and the same sequence number game over. We need
> to be absolutely sure we will rekey before that happens, and if the rekey
> fails we will disconnect. The other option - using a very long counter -
> is interesting, possibly in combination. What does the packetFormat branch
> do now?

I agree that we can't let the sequence numbers wrap since we use them for 
crypto. c73cce16..026a2845 implements the first solution you mentioned, 
refusing to send packets until after a new rekey (and starts one when needed 
of course). b2ca18a8 improves it sligthly by starting the rekey 100 packets 
before we would stop sending (this number should probably be higher, or based 
on how fast we send packets).

As for the message ids, we are safe for now because the window is so small, 
but I'll try to add some more checks just to make sure.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] More work on packet format branch

[Martin Nyhus]

On Saturday 16 October 2010 23:04:47 Matthew Toseland wrote:
> 132f4b342068e2308d6ee27ad5d95ec82fb1be2e
> - Please use /** Javadocs */ for the variables, Eclipse etc will take
> advantage of them.
Done (f10d41a)

> aed60bea24a21db858ff784d95c3b9add2e99dad
> - You need to synchronize when setting highestReceivedSequenceNumber.
> Parallel decode of messages from the same peer is likely in the near
> future (nextgens is doing some optimisation work).
Done (7c5a2bc)

> f8ed9b4d4750a34a67c7fc3f0c2e3144b95cb838
> - We should probably not use fastWeakRandom directly. It's entirely
> predictable. Probably we should create one MersenneTwister for each
> PeerNode and initialise it from the strong RNG.
I'll have a look at MersenneTwister. Should it be used for FNP too (assuming 
it isn't too much work to change it)? If so I could probably fix it there as 
well.

> 7b2a66a803688e1be8d70f3e8eb3854f7b900242
> - You should add and subtract the full overhead. Is HMAC_LENGTH the
> totality of the overhead apart from what's already accounted for in
> packet.getLength()? (I.e. the sequence number?) Looks like it is ...
HMAC_LENGTH is the length of the HMAC.

> - Arguably if we are comparing to MTUs (or plausible MTUs such as 1280) we
> should count in the UDP/IP overhead as well? (28 bytes iirc)
The UDP overhead is already subtracted by UdpPacketSender, so maxPacketSize is 
the space we can use.

> cd562aa4ebfb2a4c3b958efa8c4cd15fd7938d98
> - Arguably we should truncate the parameter to nextInt() rather than
> randomising and then clipping; we don't do this in the old code, but it
> does create a pattern as well as using more entropy than needed.
How about when padding to the first multiple of 64 would be too much? For now I 
kept the clipping of that part (see 5f03804).

> e2b0b8ee4e54b95839facdc66c781663e9f5626d
> - Did you double check that this is all either exclusively your own code or
> drawn from files that have the GPL2+ headers already?
It is all my own code

> 177f81053b5636cd74ae4aece289221e41b4fb99
> - Do we wake up the sender when we become unblocked? That's an important
> part of this too.
Done (6a9e0f8)

> 9952ed2f7b5c658cc1287d8aec98471cbba0c7f0
> - What happens if we create the packet then don't send it? Won't this waste
> a sequence number and thus cause bad things?
AFACIS there are no paths where we would create a packet and then drop it. The 
sequence number is assigned at the very end of create packet, and we can't 
return null after that, and returning null is the only thing that would make 
us return before sending in maybeSendPacket.

> > NewPacketFormat.tryDecipherPacket:
> > - Might be clearer code if you moved the sequence number assignment out
> > of the for(j), use continue outer instead of break.
Done (abeb715)

> > - Should it be updated on every packet? Obviously it should never go
> > backwards...
> "it" here means the window I guess. Should it be updated incrementally i.e.
> on every packet?
I don't see why it shouldn't, as only the sequence numbers that are outside 
the window are updated.

> > 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> > - Any particular reason for always starting from 0 on new format?
Done (807ea29)

> > 889a5cea3ed9b570f1f6e6784d34d61c9d932cd6
> > - Do we check for -1 in all getMessageID() callers?
There is only one caller, and it is checked (NewPacketFormat:538).

> > - Inconsistent synchronization in getMessageID()??
Fixed (f5f7d92)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] More work on packet format branch

[Martin Nyhus]

On Saturday 16 October 2010 23:04:47 Matthew Toseland wrote:
> 132f4b342068e2308d6ee27ad5d95ec82fb1be2e
> - Please use /** Javadocs */ for the variables, Eclipse etc will take
> advantage of them.
Done (f10d41a)

> aed60bea24a21db858ff784d95c3b9add2e99dad
> - You need to synchronize when setting highestReceivedSequenceNumber.
> Parallel decode of messages from the same peer is likely in the near
> future (nextgens is doing some optimisation work).
Done (7c5a2bc)

> f8ed9b4d4750a34a67c7fc3f0c2e3144b95cb838
> - We should probably not use fastWeakRandom directly. It's entirely
> predictable. Probably we should create one MersenneTwister for each
> PeerNode and initialise it from the strong RNG.
I'll have a look at MersenneTwister. Should it be used for FNP too (assuming 
it isn't too much work to change it)? If so I could probably fix it there as 
well.

> 7b2a66a803688e1be8d70f3e8eb3854f7b900242
> - You should add and subtract the full overhead. Is HMAC_LENGTH the
> totality of the overhead apart from what's already accounted for in
> packet.getLength()? (I.e. the sequence number?) Looks like it is ...
HMAC_LENGTH is the length of the HMAC.

> - Arguably if we are comparing to MTUs (or plausible MTUs such as 1280) we
> should count in the UDP/IP overhead as well? (28 bytes iirc)
The UDP overhead is already subtracted by UdpPacketSender, so maxPacketSize is 
the space we can use.

> cd562aa4ebfb2a4c3b958efa8c4cd15fd7938d98
> - Arguably we should truncate the parameter to nextInt() rather than
> randomising and then clipping; we don't do this in the old code, but it
> does create a pattern as well as using more entropy than needed.
How about when padding to the first multiple of 64 would be too much? For now I 
kept the clipping of that part (see 5f03804).

> e2b0b8ee4e54b95839facdc66c781663e9f5626d
> - Did you double check that this is all either exclusively your own code or
> drawn from files that have the GPL2+ headers already?
It is all my own code

> 177f81053b5636cd74ae4aece289221e41b4fb99
> - Do we wake up the sender when we become unblocked? That's an important
> part of this too.
Done (6a9e0f8)

> 9952ed2f7b5c658cc1287d8aec98471cbba0c7f0
> - What happens if we create the packet then don't send it? Won't this waste
> a sequence number and thus cause bad things?
AFACIS there are no paths where we would create a packet and then drop it. The 
sequence number is assigned at the very end of create packet, and we can't 
return null after that, and returning null is the only thing that would make 
us return before sending in maybeSendPacket.

> > NewPacketFormat.tryDecipherPacket:
> > - Might be clearer code if you moved the sequence number assignment out
> > of the for(j), use continue outer instead of break.
Done (abeb715)

> > - Should it be updated on every packet? Obviously it should never go
> > backwards...
> "it" here means the window I guess. Should it be updated incrementally i.e.
> on every packet?
I don't see why it shouldn't, as only the sequence numbers that are outside 
the window are updated.

> > 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> > - Any particular reason for always starting from 0 on new format?
Done (807ea29)

> > 889a5cea3ed9b570f1f6e6784d34d61c9d932cd6
> > - Do we check for -1 in all getMessageID() callers?
There is only one caller, and it is checked (NewPacketFormat:538).

> > - Inconsistent synchronization in getMessageID()??
Fixed (f5f7d92)


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] More work on packet format branch

[Martin Nyhus]

On Monday 2010-08-16 19:55 Matthew Toseland wrote:
> The Summer of Code firm pencils down deadline is about to expire. The
> below is concerned with the question "what must be changed to get
> this mergeable"...

> NewPacketFormat.tryDecipherPacket:
> - Should it be updated on every packet? Obviously it should never go
> backwards...
Why shouldn't it be updated on every packet (every time
highestReceivedSeqNum changes that is)? It only updates the entries
that are outside the window, so assuming packets are received in order
we update 1 entry per packet.

> 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> - Any particular reason for always starting from 0 on new format?
Both sides need to know the number because of the watchlist, so it
doesn't have to be 0, but it has to be generated using something other
than random.nextInt().

> 501bb6dfe50a6e54bd0c19d867c1136eed37128c
> - Not sure this is a good idea, old format is limited to 512 packets
> in flight (or was it 256?) and has lots of retransmit stuff etc you
> don't need.
> - This has the advantage of keeping the would block handling, but on
> the other hand it has a nasty packet window limit, lots of code
> related to old format retransmission code (which is bad); the
> retransmission logic e.g. is completely inappropriate.
I forgot that the window was in PacketTracker, so I'll probably revert
this one and wrap the sequence numbers instead of using them per key.

Other things that need to be fixed:

Support for padding
  The easiest way of doing this might be to use the flag combination
  that is currently illegal (not fragmented and not first packet) to
  indicate that the rest of the packet is padding.

Longer HMAC
  Currently the HMAC length is set to 4 bytes which is too short, and
  having a variable length has also been mentioned.

Busy-loop in PacketSender/maybeSendPacket()

-- 
Martin Nyhus
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20100819/37f9342c/attachment.pgp>

Re: [freenet-dev] More work on packet format branch

[Martin Nyhus]

On Monday 2010-08-16 19:55 Matthew Toseland wrote:
> The Summer of Code firm pencils down deadline is about to expire. The
> below is concerned with the question "what must be changed to get
> this mergeable"...

> NewPacketFormat.tryDecipherPacket:
> - Should it be updated on every packet? Obviously it should never go
> backwards...
Why shouldn't it be updated on every packet (every time
highestReceivedSeqNum changes that is)? It only updates the entries
that are outside the window, so assuming packets are received in order
we update 1 entry per packet.

> 2e33916fee9106b0e985f1bf974ed3d8fda40f42
> - Any particular reason for always starting from 0 on new format?
Both sides need to know the number because of the watchlist, so it
doesn't have to be 0, but it has to be generated using something other
than random.nextInt().

> 501bb6dfe50a6e54bd0c19d867c1136eed37128c
> - Not sure this is a good idea, old format is limited to 512 packets
> in flight (or was it 256?) and has lots of retransmit stuff etc you
> don't need.
> - This has the advantage of keeping the would block handling, but on
> the other hand it has a nasty packet window limit, lots of code
> related to old format retransmission code (which is bad); the
> retransmission logic e.g. is completely inappropriate.
I forgot that the window was in PacketTracker, so I'll probably revert
this one and wrap the sequence numbers instead of using them per key.

Other things that need to be fixed:

Support for padding
  The easiest way of doing this might be to use the flag combination
  that is currently illegal (not fragmented and not first packet) to
  indicate that the rest of the packet is padding.

Longer HMAC
  Currently the HMAC length is set to 4 bytes which is too short, and
  having a variable length has also been mentioned.

Busy-loop in PacketSender/maybeSendPacket()

-- 
Martin Nyhus


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Code review of recent work on new packet format

[Martin Nyhus]

(With CC to devl@ this time)

On Friday 2010-08-06 00:24 Matthew Toseland wrote:
> e498d8d502a64e1413ebdf69e05ce0940d140d02
> - can item.buf.length be < end ?
Yes, eg. if we haven't sent anything from this message yet, sent is
empty, so end = Integer.MAX_VALUE.

> d49933fadd01ab44145dc8346fa43cb0d4812d76
> - is a default of 0 a good idea??
Not sure. I haven't seen any problems, but for now I've changed it to
250ms (minimum rtt returned by PacketTracker.twoRTTs()), so if it
matters we will resend a lot less on startup.

> ac10be3f2059c89e42e23de8613b86e46fd013ee
> - how long will it take for us to go through 268M message ID's? it
> should be safe to wrap as long as the packet-level delta is so large
> that there is no possibility of confusion, so it doesn't affect
> rekeying, correct? (Actually rekeying has to be separate from the
> message sequence anyway ...)
The testnodes I'm running right now will run out in 2 years (12h
uptime, ~170k and ~85k ids), but then again they to nothing...

It should be safe to wrap, both because of the packet numbers, but they
will run out too. It looks like FNP uses per-key packet numbers, but
doing it that way means they start over at unknown intervals, so they
can't be used for checking the message ids (or can it be done?).

> 1ad9015e0b642d52ce5096a1452b23068aaea19a
> - packet sequence numbers appear to be per-SessionKey? are message
> sequence numbers global (for a peer) while packet sequence numbers
> are per-encryption key (and potentially per-transport as well)?
They are both per-peer. Message ids have to be, packet numbers is
related to the above point.

> - IMHO this should be a rolling window, rather than being
> periodically refreshed. I.e. you maintain a pointer within the
> buffer, and when you accept a packet you move the pointer and update
> the slots behind it. And because the IV is generated from the packet
> number, you will need to use the offset of the match to tell you the
> packet number in order to do the decryption. But maybe I'm wrong?
Sounds good. I think I've got a reasonably good way of doing it, so it
should be fixed soon.

> 9c43896c682115f47ea2fc669bc7f6d5cb08c2aa
> - HERE BE DRAGONS 
> - I spent a significant amount of time on issues related to this on
> the old packet format.
> - On the old packet format, we could not send packet N+256 until
> packet N had been acknowledged. But we still needed to be able to
> send ack's, and we don't want to busy loop. Hence if we can't send a
> packet with a sequence number, we send one without a sequence number
> (seqno=-1), containing only acks. The problem is that we can't reuse
> the same seqno in the new packet format because the IV is derived
> from the seqno and the IV must be unique for a packet.
> - IMHO you do *not* need to take into account the receive window as
> you do here. Packets are generally delivered in order, so you can
> have a lot more packets in flight than the decryption window and
> still have all of them decrypt correctly; and this is likely to be
> the case anywhere where you have a high round trip time.
> - Is there any other reason to arbitrarily limit the number of packet
> sequence numbers in flight? [...]
None that I know of, so I guess the limit can be dropped.

> d5d5d6c52d1690be2872f07502cef9a45058c16b
> - I don't understand why this commit is useful or necessary.
> MessageWrapper's are all wrapping MessageItem's, aren't they? So they
> will get told of disconnect anyway?
PeerNode calls onDisconnect() for the items on the queue, but not for
items that we've started to send.

> 7d80c2ca4d28f7ae0a01bb515ad00543c2954c5d
> - Can we optimise the sender size for high packet loss by e.g. trying
> to complete existing fragmented sends, possibly one at a time, before
> starting new ones?
Assuming you meant the sender side, it shouldn't be to hard to do, even
after it has been put into use. If you meant size, I've got no idea
what you are asking...


-- 
Martin Nyhus
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20100809/d5472919/attachment.pgp>

Re: [freenet-dev] Code review of recent work on new packet format

[Martin Nyhus]

(With CC to devl@ this time)

On Friday 2010-08-06 00:24 Matthew Toseland wrote:
> e498d8d502a64e1413ebdf69e05ce0940d140d02
> - can item.buf.length be < end ?
Yes, eg. if we haven't sent anything from this message yet, sent is
empty, so end = Integer.MAX_VALUE.

> d49933fadd01ab44145dc8346fa43cb0d4812d76
> - is a default of 0 a good idea??
Not sure. I haven't seen any problems, but for now I've changed it to
250ms (minimum rtt returned by PacketTracker.twoRTTs()), so if it
matters we will resend a lot less on startup.

> ac10be3f2059c89e42e23de8613b86e46fd013ee
> - how long will it take for us to go through 268M message ID's? it
> should be safe to wrap as long as the packet-level delta is so large
> that there is no possibility of confusion, so it doesn't affect
> rekeying, correct? (Actually rekeying has to be separate from the
> message sequence anyway ...)
The testnodes I'm running right now will run out in 2 years (12h
uptime, ~170k and ~85k ids), but then again they to nothing...

It should be safe to wrap, both because of the packet numbers, but they
will run out too. It looks like FNP uses per-key packet numbers, but
doing it that way means they start over at unknown intervals, so they
can't be used for checking the message ids (or can it be done?).

> 1ad9015e0b642d52ce5096a1452b23068aaea19a
> - packet sequence numbers appear to be per-SessionKey? are message
> sequence numbers global (for a peer) while packet sequence numbers
> are per-encryption key (and potentially per-transport as well)?
They are both per-peer. Message ids have to be, packet numbers is
related to the above point.

> - IMHO this should be a rolling window, rather than being
> periodically refreshed. I.e. you maintain a pointer within the
> buffer, and when you accept a packet you move the pointer and update
> the slots behind it. And because the IV is generated from the packet
> number, you will need to use the offset of the match to tell you the
> packet number in order to do the decryption. But maybe I'm wrong?
Sounds good. I think I've got a reasonably good way of doing it, so it
should be fixed soon.

> 9c43896c682115f47ea2fc669bc7f6d5cb08c2aa
> - HERE BE DRAGONS 
> - I spent a significant amount of time on issues related to this on
> the old packet format.
> - On the old packet format, we could not send packet N+256 until
> packet N had been acknowledged. But we still needed to be able to
> send ack's, and we don't want to busy loop. Hence if we can't send a
> packet with a sequence number, we send one without a sequence number
> (seqno=-1), containing only acks. The problem is that we can't reuse
> the same seqno in the new packet format because the IV is derived
> from the seqno and the IV must be unique for a packet.
> - IMHO you do *not* need to take into account the receive window as
> you do here. Packets are generally delivered in order, so you can
> have a lot more packets in flight than the decryption window and
> still have all of them decrypt correctly; and this is likely to be
> the case anywhere where you have a high round trip time.
> - Is there any other reason to arbitrarily limit the number of packet
> sequence numbers in flight? [...]
None that I know of, so I guess the limit can be dropped.

> d5d5d6c52d1690be2872f07502cef9a45058c16b
> - I don't understand why this commit is useful or necessary.
> MessageWrapper's are all wrapping MessageItem's, aren't they? So they
> will get told of disconnect anyway?
PeerNode calls onDisconnect() for the items on the queue, but not for
items that we've started to send.

> 7d80c2ca4d28f7ae0a01bb515ad00543c2954c5d
> - Can we optimise the sender size for high packet loss by e.g. trying
> to complete existing fragmented sends, possibly one at a time, before
> starting new ones?
Assuming you meant the sender side, it shouldn't be to hard to do, even
after it has been put into use. If you meant size, I've got no idea
what you are asking...


-- 
Martin Nyhus


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] zidel's new packet format branch

[Martin Nyhus]

On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote:
> 866a2aa9ee74434d6ad4328dc8c5edaa75b779f6
> - synchronize when allocating a sequence number!!
Fixed in fee766aeba5c167497031357af68d5b446ffa090

> 59e7088ca13761253eb1729b9e4c9f73af6ae205
> - Here and elsewhere sign extension on bytes can trip you up. You
> need to do & 0xff on the byte values, or use one of our provided
> methods for decoding, or mask the whole thing afterwards e.g. value =
> value | 0xff.
AFAIK all of these are fixed in various later commits

> 78aced73420599f544cf6aefca188ca9963b28d4
> - assertTrue(s.contains(3, 2));
> - this should throw!
Copy paste fail...
Test fixed in b49ad5b3cc9f3b5d6b4349f64164ab1acc59c6b1
Throws in 67d01ba9446c29facfc40cfe3307a9f3b3f7d1b0

> f32ee7587ce8a3fa80574b35505aa66a080ef084
> + //TODO: If the other side resends a
> packet after we have gotten all the data, we will
> + //never ack the resent packet
> - The standard solution to this is to ack resent packets. If we have
> processed a packet and we get a resend for it, ack it.
This specific issue doesn't exist anymore. The larger problem will be
solved when we find a good way to deal with the message ids

> cd7d374b7823906a46a46a417fdface43bbe188a
> - I'm not sure this is wise - if we use a full HMAC on big packets,
> that might kick the encrypted sequence number into the second block,
> thus becoming unpredictable? OTOH if we use an HMAC of the encrypted
> data (keyed from a key other than the encryption key), and don't
> encrypt it itself, it won't be a problem.
Shouldn't be a problem since the encryption is done starting at the
sequence number. (using different keys for lots of things is on my
todo-list)

> 0a92c3f7a14d1f44f1f25013d045fbbeb2ff867b
> - Can isFragmented() be bogus here with border cases? It is
> calculated based on the maximum header length - if it returns false
> and then we discover that with the actual header length we don't need
> to fragment, what happens?
That code has been changed a lot since that commit, but I'm pretty sure
the fragmentation works correctly atm. Fragmentation logic was
rewritten in e498d8d502a64e1413ebdf69e05ce0940d140d02.

> 17096df5098e53881db1a6957c41b6c83e0ad4ec
> - If frag == null, do we lose the message from the queue here?
Yes. Fixed in 1cc94e41b6e7b64ceaf249426d193c843b6baf82

> 5c537e76f15e8ef9e4ed974e5a41a31fd720f3b1
> - Doesn't item itself have a method to call all the acks? it should...
It doesn't, and what PacketTracker did looked non-trivial, so I've
added it to my todo-list.

In case anyone would like to fix it, the duplicated code is at:
src/freenet/node/MessageWrapper.java:37
src/freenet/node/PacketTracker.java:542
src/freenet/node/PacketTracker.java:588
(commit 1cc94e41b6e7b64ceaf249426d193c843b6baf82)

> bc1eb2fa33c0b2063992df3fb9b207c8c7b66f0c
> - The unit test doesn't test what it says. The bytes should each be
> different to be sure about this.
Fixed in 3bc052c6c3f16e8beedf152d0b0088bb6e3109a0

> 7a316c720fcaed368d7ad35f8a1262aa4f91dce7
> - it shouldn't be added if it's bad
Fixed in 24cd2e093de160ebdb8de583cdb1727420e3bee0

> b58aa213ed98f814eaab2c9893d1b12d4578c04e
> - remove the sentPacket when returning due to no key???
Fixed in 70b1586ead668692836fc58715045945843cf002

> a1acd68b51cc124a11ed1d496c82f82ce279da3a
> - Don't count the RTT slots that haven't been filled in!
Fixed in 1ceb102eeef5009ee43161ad5562e4bef790d022

> 8f561a3ce585170c55a678e0cc0d62b6ab639a25
> - Use entrySet() and Map.Entry<>.
Fixed in 394e5151be5422452a939d4d76444069644ffba2

> 899528d44d43b42d2ca8a304d9ecfe4847a5c50b
> Use maximum not average of last 10 RTTs
> - Is this a good idea?
Probably not. IIRC I didn't mean to push that, so reverted as
1da1bcfcb38f220ce21e1f3d9ef6fedb73fe24db

-- 
Martin Nyhus
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20100727/05969033/attachment.pgp>

[freenet-dev] zidel's new packet format branch

[Martin Nyhus]

On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote:
> - How to make message ID re-use safe, or how to not re-use message
> ID's and still not use unreasonable numbers of bytes.
[...]
> - We allow up to 8192 messages in flight. We use the top few bits for
> flags. We recycle message ID's. * Is it safe to recycle
> message ID's - even in the presence of replays and delayed packets?
[...]
> - Message seqno's are reused. * We need to seriously consider
> this, I'm not sure it's safe, even with a packet-level window. How
> can it be made safe? Safe = we get a somewhat delayed packet, it
> contains a chunk from message 1, we can be confident that wasn't from
> the previous message 1.
I haven't been able to convince myself that reusing ids can be done
safely, and not reusing ids would solve the issue of how many messages
we can keep in flight, so using two bytes extra (based on your idea on
irc some time ago) might be worth it, especially considering bulk
transfers.

> - Acceptable length of an HMAC.
[...]
> - Use first 4 bytes of SHA256 as HMAC. * TOO SHORT  Maybe
> should be variable depending on packet size? RESEARCH THIS!
The length is in a constant, so it's very easy to change, but I don't
know how long it should be. FNP uses the full SHA256.

> - Appropriate window size for packet numbers.
This might depend on what we do with the message ids, but other than
that I think this is a question of how many sequence numbers we want to
watch for.

> - We still use one 4 byte ack and then 1 byte deltas. ** We
> should compress each ack relative to the preceding ack, not relative
> to the first ack (and sort them, of course)
Fixed in 4f08a3e13de550f0c15f910a8e23b73ac18592f4

> - Add SparseBitmap class to contain range tracking logic. Similar
> code was in ReceivedPacketNumbers and temporarily in MessageWrapper.
Using this in ReceivedPacketNumbers is on my todo-list, but after GSoC.

> - ** IIRC TCP resends immediately if it sees a later sequence
> number? This reduces latency but will occasionally result in
> unnecessary resends? I think what TCP does is this: If a packet
> hasn't been acked after 4 RTT's (you can get this from
> PeerNode.fourRTTs()), we resend it; and if we get an ack for a
> packet, we assume those before it haven't arrived and resend them. I
> may be remembering wrong, there's something about 1.5 RTTs somewhere?
> Look it up, maybe on the wiki page? What the old FNP code does is
> hideous, of course.
I couldn't find the details on TCP at first glance, but improving the
resend logic is on my todo-list.

-- 
Martin Nyhus
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20100727/deaf6276/attachment.pgp>

Re: [freenet-dev] zidel's new packet format branch

[Martin Nyhus]

On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote:
> 866a2aa9ee74434d6ad4328dc8c5edaa75b779f6
> - synchronize when allocating a sequence number!!
Fixed in fee766aeba5c167497031357af68d5b446ffa090

> 59e7088ca13761253eb1729b9e4c9f73af6ae205
> - Here and elsewhere sign extension on bytes can trip you up. You
> need to do & 0xff on the byte values, or use one of our provided
> methods for decoding, or mask the whole thing afterwards e.g. value =
> value | 0xff.
AFAIK all of these are fixed in various later commits

> 78aced73420599f544cf6aefca188ca9963b28d4
> - assertTrue(s.contains(3, 2));
> - this should throw!
Copy paste fail...
Test fixed in b49ad5b3cc9f3b5d6b4349f64164ab1acc59c6b1
Throws in 67d01ba9446c29facfc40cfe3307a9f3b3f7d1b0

> f32ee7587ce8a3fa80574b35505aa66a080ef084
> + //TODO: If the other side resends a
> packet after we have gotten all the data, we will
> + //never ack the resent packet
> - The standard solution to this is to ack resent packets. If we have
> processed a packet and we get a resend for it, ack it.
This specific issue doesn't exist anymore. The larger problem will be
solved when we find a good way to deal with the message ids

> cd7d374b7823906a46a46a417fdface43bbe188a
> - I'm not sure this is wise - if we use a full HMAC on big packets,
> that might kick the encrypted sequence number into the second block,
> thus becoming unpredictable? OTOH if we use an HMAC of the encrypted
> data (keyed from a key other than the encryption key), and don't
> encrypt it itself, it won't be a problem.
Shouldn't be a problem since the encryption is done starting at the
sequence number. (using different keys for lots of things is on my
todo-list)

> 0a92c3f7a14d1f44f1f25013d045fbbeb2ff867b
> - Can isFragmented() be bogus here with border cases? It is
> calculated based on the maximum header length - if it returns false
> and then we discover that with the actual header length we don't need
> to fragment, what happens?
That code has been changed a lot since that commit, but I'm pretty sure
the fragmentation works correctly atm. Fragmentation logic was
rewritten in e498d8d502a64e1413ebdf69e05ce0940d140d02.

> 17096df5098e53881db1a6957c41b6c83e0ad4ec
> - If frag == null, do we lose the message from the queue here?
Yes. Fixed in 1cc94e41b6e7b64ceaf249426d193c843b6baf82

> 5c537e76f15e8ef9e4ed974e5a41a31fd720f3b1
> - Doesn't item itself have a method to call all the acks? it should...
It doesn't, and what PacketTracker did looked non-trivial, so I've
added it to my todo-list.

In case anyone would like to fix it, the duplicated code is at:
src/freenet/node/MessageWrapper.java:37
src/freenet/node/PacketTracker.java:542
src/freenet/node/PacketTracker.java:588
(commit 1cc94e41b6e7b64ceaf249426d193c843b6baf82)

> bc1eb2fa33c0b2063992df3fb9b207c8c7b66f0c
> - The unit test doesn't test what it says. The bytes should each be
> different to be sure about this.
Fixed in 3bc052c6c3f16e8beedf152d0b0088bb6e3109a0

> 7a316c720fcaed368d7ad35f8a1262aa4f91dce7
> - it shouldn't be added if it's bad
Fixed in 24cd2e093de160ebdb8de583cdb1727420e3bee0

> b58aa213ed98f814eaab2c9893d1b12d4578c04e
> - remove the sentPacket when returning due to no key???
Fixed in 70b1586ead668692836fc58715045945843cf002

> a1acd68b51cc124a11ed1d496c82f82ce279da3a
> - Don't count the RTT slots that haven't been filled in!
Fixed in 1ceb102eeef5009ee43161ad5562e4bef790d022

> 8f561a3ce585170c55a678e0cc0d62b6ab639a25
> - Use entrySet() and Map.Entry<>.
Fixed in 394e5151be5422452a939d4d76444069644ffba2

> 899528d44d43b42d2ca8a304d9ecfe4847a5c50b
> Use maximum not average of last 10 RTTs
> - Is this a good idea?
Probably not. IIRC I didn't mean to push that, so reverted as
1da1bcfcb38f220ce21e1f3d9ef6fedb73fe24db

-- 
Martin Nyhus


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] zidel's new packet format branch

[Martin Nyhus]

On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote:
> - How to make message ID re-use safe, or how to not re-use message
> ID's and still not use unreasonable numbers of bytes.
[...]
> - We allow up to 8192 messages in flight. We use the top few bits for
> flags. We recycle message ID's. * Is it safe to recycle
> message ID's - even in the presence of replays and delayed packets?
[...]
> - Message seqno's are reused. * We need to seriously consider
> this, I'm not sure it's safe, even with a packet-level window. How
> can it be made safe? Safe = we get a somewhat delayed packet, it
> contains a chunk from message 1, we can be confident that wasn't from
> the previous message 1.
I haven't been able to convince myself that reusing ids can be done
safely, and not reusing ids would solve the issue of how many messages
we can keep in flight, so using two bytes extra (based on your idea on
irc some time ago) might be worth it, especially considering bulk
transfers.

> - Acceptable length of an HMAC.
[...]
> - Use first 4 bytes of SHA256 as HMAC. * TOO SHORT  Maybe
> should be variable depending on packet size? RESEARCH THIS!
The length is in a constant, so it's very easy to change, but I don't
know how long it should be. FNP uses the full SHA256.

> - Appropriate window size for packet numbers.
This might depend on what we do with the message ids, but other than
that I think this is a question of how many sequence numbers we want to
watch for.

> - We still use one 4 byte ack and then 1 byte deltas. ** We
> should compress each ack relative to the preceding ack, not relative
> to the first ack (and sort them, of course)
Fixed in 4f08a3e13de550f0c15f910a8e23b73ac18592f4

> - Add SparseBitmap class to contain range tracking logic. Similar
> code was in ReceivedPacketNumbers and temporarily in MessageWrapper.
Using this in ReceivedPacketNumbers is on my todo-list, but after GSoC.

> - ** IIRC TCP resends immediately if it sees a later sequence
> number? This reduces latency but will occasionally result in
> unnecessary resends? I think what TCP does is this: If a packet
> hasn't been acked after 4 RTT's (you can get this from
> PeerNode.fourRTTs()), we resend it; and if we get an ack for a
> packet, we assume those before it haven't arrived and resend them. I
> may be remembering wrong, there's something about 1.5 RTTs somewhere?
> Look it up, maybe on the wiki page? What the old FNP code does is
> hideous, of course.
I couldn't find the details on TCP at first glance, but improving the
resend logic is on my todo-list.

-- 
Martin Nyhus


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

On Sat, 29 May 2010 15:56:29 Matthew Toseland wrote:

> Sorry for the delay, been busy. Please fight me wherever I am wrong,
> inform me wherever I am misunderstanding etc.
> 
> On Monday 24 May 2010 12:09:36 Martin Nyhus wrote:
> > Except moving the FNP code, the only structural change I can think
> > of right now is moving the block transfer code, but as you mention,
> > it should wait until after the packet format is done. I haven't
> > looked closely at the crypto code yet, so I might need to do
> > something there.
> 
> Well can you give me a reasonable idea of what FNP code you are
> proposing to move? I am concerned that we not rewrite stuff
> unnecessarily?

There isn't a whole lot that has to be moved, and it should be fairly
easy to do so. What I would like to move is sendAsync(), the message
queue, requeueMessageItems(), maybeSendPacket() and some small methods.
Basically something like [0], but with proper synchronization etc. IMHO
it should be possible to do all of this while only rewriting minor
pieces.

[0]
http://github.com/zidel/fred-staging/commit/42ea5e9d700c21a2e2f3627dc6fefc13c3d1be67
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20100530/06f8d4f9/attachment.pgp>

Re: [freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

On Sat, 29 May 2010 15:56:29 Matthew Toseland wrote:

> Sorry for the delay, been busy. Please fight me wherever I am wrong,
> inform me wherever I am misunderstanding etc.
> 
> On Monday 24 May 2010 12:09:36 Martin Nyhus wrote:
> > Except moving the FNP code, the only structural change I can think
> > of right now is moving the block transfer code, but as you mention,
> > it should wait until after the packet format is done. I haven't
> > looked closely at the crypto code yet, so I might need to do
> > something there.
> 
> Well can you give me a reasonable idea of what FNP code you are
> proposing to move? I am concerned that we not rewrite stuff
> unnecessarily?

There isn't a whole lot that has to be moved, and it should be fairly
easy to do so. What I would like to move is sendAsync(), the message
queue, requeueMessageItems(), maybeSendPacket() and some small methods.
Basically something like [0], but with proper synchronization etc. IMHO
it should be possible to do all of this while only rewriting minor
pieces.

[0]
http://github.com/zidel/fred-staging/commit/42ea5e9d700c21a2e2f3627dc6fefc13c3d1be67


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

On Sat, 22 May 2010 17:17:41 Matthew Toseland wrote:
> Did you have any specific structural changes you were thinking of as
> a first step?

Except moving the FNP code, the only structural change I can think of
right now is moving the block transfer code, but as you mention, it
should wait until after the packet format is done. I haven't looked
closely at the crypto code yet, so I might need to do something there.

> However, it will be necessary to keep support for old style bulk
> transfers for quite some time because it is needed for Update Over
> Mandatory to continue to work.

Hopefully the bulk transfer code will only be needed if we use
FNP, and as long as the new packet format isn't merged before moving
bulk transfer I think it should work out.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

Re: [freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

On Sat, 22 May 2010 17:17:41 Matthew Toseland wrote:
> Did you have any specific structural changes you were thinking of as
> a first step?

Except moving the FNP code, the only structural change I can think of
right now is moving the block transfer code, but as you mention, it
should wait until after the packet format is done. I haven't looked
closely at the crypto code yet, so I might need to do something there.

> However, it will be necessary to keep support for old style bulk
> transfers for quite some time because it is needed for Update Over
> Mandatory to continue to work.

Hopefully the bulk transfer code will only be needed if we use
FNP, and as long as the new packet format isn't merged before moving
bulk transfer I think it should work out.


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

I've tried to think about how to implement the new packet format, while
keeping the old code around. My plan so far is to move all the FNP
related code from PeerNode to a new class, and have PeerNode use the
old code through this class.

The new code can then be added without touching FNP, and PeerNode will
choose which format to use for each peer. At the moment I'm not sure
how to select which format to use. It obviously depends on the peer, so
is there anything in the node ref that can be used to decide that the
peer supports 'FNP v2'? If not, can something be added without breaking
old nodes, or is there a better way of doing this?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

[freenet-dev] Implementation of Evans packet format

[Martin Nyhus]

I've tried to think about how to implement the new packet format, while
keeping the old code around. My plan so far is to move all the FNP
related code from PeerNode to a new class, and have PeerNode use the
old code through this class.

The new code can then be added without touching FNP, and PeerNode will
choose which format to use for each peer. At the moment I'm not sure
how to select which format to use. It obviously depends on the peer, so
is there anything in the node ref that can be used to decide that the
peer supports 'FNP v2'? If not, can something be added without breaking
old nodes, or is there a better way of doing this?


signature.asc
Description: PGP signature
___
Devl mailing list
Devl@freenetproject.org
http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl

[freenet-dev] Changing defaults in FlogHelper

[Martin Nyhus]

On Thursday 08 April 2010 20:17:39 Matthew Toseland wrote:
> Why are you overriding the defaults in
> 95d840108aa0321cb259e59b89face076db8bdea ?
> Fork on cacheable is on by default iirc. Certainly it should be.

Evan pointed me to the wiki[0] after I made the first commit, so I changed it 
to the defaults listed on the wiki. Looking at the source fork on cacheable is 
set to true by default in Node.

> Extra inserts for a single block should IMHO be set to 2 in FlogHelper
> because this will improve retrievability.

Pushed to github[1]

[0] http://new-wiki.freenetproject.org/FCPv2/ClientPut
[1] git://github.com/zidel/plugin-FlogHelper-staging.git

-- 
Martin Nyhus

Re: [freenet-dev] Changing defaults in FlogHelper

[Martin Nyhus]

On Thursday 08 April 2010 20:17:39 Matthew Toseland wrote:
> Why are you overriding the defaults in
> 95d840108aa0321cb259e59b89face076db8bdea ?
> Fork on cacheable is on by default iirc. Certainly it should be.

Evan pointed me to the wiki[0] after I made the first commit, so I changed it 
to the defaults listed on the wiki. Looking at the source fork on cacheable is 
set to true by default in Node.

> Extra inserts for a single block should IMHO be set to 2 in FlogHelper
> because this will improve retrievability.

Pushed to github[1]

[0] http://new-wiki.freenetproject.org/FCPv2/ClientPut
[1] git://github.com/zidel/plugin-FlogHelper-staging.git

-- 
Martin Nyhus
___
Devl mailing list
Devl@freenetproject.org
http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl

[freenet-dev] Firefox and Freenet

[Martin Nyhus]

On Fri, 2008-03-07 at 11:43 +, Matthew Toseland wrote:
> On Friday 07 March 2008 02:03, Florent Daigni?re wrote:
> > They are numerous techniques to find it out; using the number of
> > simultaneous connections the browser allows is less reliable than using
> > http://ha.ckers.org/weird/CSS-history-hack.html for instance.
> 
> Nice. That's strictly an exploit, but not likely to be fixed (or does it not 
> work in 3.0?). However, this would ALSO be solved by using an external 
> profile for browsing freenet, because the cache and browser history are 
> stored in the profile directory. IMHO this is the way to go... how exactly do 
> we go about creating a profile directory for feeding to firefox? One minor 
> thing: it should have a recognisably different theme, so that the user 
> doesn't confuse it with their default browser. Anyone want to make one?

Creating a profile is really easy, just point Firefox to the folder you
want, if it's empty a new profile is made in that folder, if not it will
use the existing profile, and if the folder doesn't exist it won't start
at all.

I've attached a profile with a some minor changes and the Simple
Green[1] theme, and extensions can also be included.

[1] https://addons.mozilla.org/en-US/firefox/addon/6269

Nogaso
-- next part --
A non-text attachment was scrubbed...
Name: profile.zip
Type: application/zip
Size: 552402 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: 

[freenet-dev] [freenet-cvs] r16923 - trunk/freenet/src/freenet/store

[Martin Nyhus]

On Saturday 5. January 2008 22:26:37 toad at freenetproject.org wrote:
> Author: toad
> Date: 2008-01-05 21:26:37 + (Sat, 05 Jan 2008)
> New Revision: 16923
>
> Modified:
>trunk/freenet/src/freenet/store/BerkeleyDBFreenetStore.java
> Log:
> demote to DEBUG level logging
[...]
> @@ -1580,9 +1573,9 @@
>   if(keysRAF != null) {
>   keysRAF.seek(blockNum * keyLength);
>   keysRAF.write(fullKey);
> - if(logMINOR)
> + if(logDEBUG)
>   Logger.minor(this, "Written full key 
> length "+fullKey.length+" to 
block "+blockNum+" at "+(blockNum * keyLength));
> - } else if(logMINOR && storeType == TYPE_SSK) {
> + } else if(logDEBUG && storeType == TYPE_SSK) {
>   Logger.minor(this, "Not writing full key length 
> "+fullKey.length+" for 
block "+blockNum);
>   }

Shouldn't Logger.minor be Logger.debug here?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] [freenet-cvs] r16923 - trunk/freenet/src/freenet/store

[Martin Nyhus]

On Saturday 5. January 2008 22:26:37 [EMAIL PROTECTED] wrote:
> Author: toad
> Date: 2008-01-05 21:26:37 + (Sat, 05 Jan 2008)
> New Revision: 16923
>
> Modified:
>trunk/freenet/src/freenet/store/BerkeleyDBFreenetStore.java
> Log:
> demote to DEBUG level logging
[...]
> @@ -1580,9 +1573,9 @@
>   if(keysRAF != null) {
>   keysRAF.seek(blockNum * keyLength);
>   keysRAF.write(fullKey);
> - if(logMINOR)
> + if(logDEBUG)
>   Logger.minor(this, "Written full key 
> length "+fullKey.length+" to 
block "+blockNum+" at "+(blockNum * keyLength));
> - } else if(logMINOR && storeType == TYPE_SSK) {
> + } else if(logDEBUG && storeType == TYPE_SSK) {
>   Logger.minor(this, "Not writing full key length 
> "+fullKey.length+" for 
block "+blockNum);
>   }

Shouldn't Logger.minor be Logger.debug here?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Mozilla/Gecko browser features destroying your anonymity on freenet?

[Martin Nyhus]

On Sun, 2007-12-09 at 05:50 -0800, Jack O'Lantern wrote:
> * Safebrowsing: communicates the URL (and contents?) of each request to
> a "safebrowsing provider" (Google is the default). This feature appears
> to be deactivated in most, if not all, browsers by default. It may be
> deactivated by setting "browser.safebrowsing.enabled" to false.

According to mozillaZine[1], setting
"browser.safebrowsing.remoteLookups" to false should be enough to stop
remote lookups.

[1] http://kb.mozillazine.org/Browser.safebrowsing.remoteLookups
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: 

Re: [freenet-dev] Mozilla/Gecko browser features destroying your anonymity on freenet?

[Martin Nyhus]

On Sun, 2007-12-09 at 05:50 -0800, Jack O'Lantern wrote:
> * Safebrowsing: communicates the URL (and contents?) of each request to
> a "safebrowsing provider" (Google is the default). This feature appears
> to be deactivated in most, if not all, browsers by default. It may be
> deactivated by setting "browser.safebrowsing.enabled" to false.

According to mozillaZine[1], setting
"browser.safebrowsing.remoteLookups" to false should be enough to stop
remote lookups.

[1] http://kb.mozillazine.org/Browser.safebrowsing.remoteLookups


signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Updated Norwegian translation

[Martin Nyhus]

A few new and updated strings for the Norwegian translation
-- next part --
BookmarkEditorToadlet.urlDecodeError=Feil ved dekoding av URL
ConfigToadlet.possibilitiesTitle=Dine muligheter
ConnectionsToadlet.nodeStatus.BACKED OFF=OPPTATT
ConnectionsToadlet.nodeStatus.BUSY=OPPTATT
ConnectionsToadlet.nodeStatus.CLOCK PROBLEM=KLOKKEPROBLEM
ConnectionsToadlet.nodeStatus.CONNECTED=TILKOPLET
ConnectionsToadlet.nodeStatus.CONNECTION ERROR=TILKOPLINGSFEIL
ConnectionsToadlet.nodeStatus.DISABLED=DEAKTIVERT
ConnectionsToadlet.nodeStatus.DISCONNECTED=FRAKOPLET
ConnectionsToadlet.nodeStatus.DISCONNECTING=KOBLER FRA
ConnectionsToadlet.nodeStatus.LISTEN ONLY=BARE LYTT
ConnectionsToadlet.nodeStatus.LISTENING=LYTTER
ConnectionsToadlet.nodeStatus.NEVER CONNECTED=ALDRI TILKOPLET
ConnectionsToadlet.nodeStatus.TOO NEW=FOR NY
ConnectionsToadlet.nodeStatus.TOO OLD=FOR GAMMEL
ConnectionsToadlet.nodeStatus.UNKNOWN STATUS=UKJENT STATUS
DarknetConnectionsToadlet.addPeerTitle=Legg til en ny node
DarknetConnectionsToadlet.backedOff=Tilkoblet, men opptatt: Disse nodene er 
tilkoblet, men er opptatt, s? noden din sender ingen foresp?rsler til dem.
DarknetConnectionsToadlet.busy=Opptatt: Disse nodene er tilkoblet, men for 
opptatt til ? svare p? v?re foresp?rsler, s? noden din sender ingen 
foresp?rsler til dem.
DarknetConnectionsToadlet.disabled=Ikke tilkoblet og deaktivert: Du har 
instruert noden din til ikke ? koble til disse nodene.
DarknetConnectionsToadlet.listenOnly=Ikke tilkoblet og bare lytter: noden din 
vil ikke pr?ve ? koble til disse nodene, fordi brukeren har markert de med 
BareLytt.
DarknetConnectionsToadlet.neverConnected=Aldri tilkoblet: Noden din har aldri 
koblet til disse nodene.
DarknetConnectionsToadlet.noPeersWithHomepageLink=Freenet kan ikke fungere 
ettersom du ikke har lagt til noen noder s? langt. Vennligst g? til 
${link}nodens hjemmeside${/link} og les den ?verste infoboksen for ? se hvordan 
dette gj?res.
DarknetConnectionsToadlet.privateNote=Et privat notat om denne noden
DarknetConnectionsToadlet.removePeers=Fjern valgte noder
DarknetConnectionsToadlet.tooNew=Tilkoblet, men for ny: Disse nodenes laveste 
obligatoriske versjon er h?yere enn din nodes versjonsnummer.
DarknetConnectionsToadlet.tooOld=Tilkoplet, men for gammel: Din nodes laveste 
obligatoriske versjon er h?yere enn denne nodens versjonsnummer. Noden din vil 
ikke sende foresp?rsler til denne noden.
DarknetConnectionsToadlet.triedToAddSelf=Du kan ikke legge til din egen node 
til listen over eksterne noder.
FProxyToadlet.opennet=Administrer fremmede noder
FProxyToadlet.plugins=Administrer tillegg
MeaningfulNodeNameUserAlert.noNodeNick=Det virker som noden din ikke vet om 
pseudonymet ditt. Generelt sett er det en god ide ? legge inn e-mail adressen 
din eller IRC pseudonymet ditt her s? vennene dine lettere kan identifisere 
noden din (merk at bare venner kan se node-navnet ditt, det vises ikke til 
fremmede).
OpennetConnectionsToadlet.fullTitle=${counts} Fremmede (ukjente noder) 
tilkoblet ${name}
OpennetConnectionsToadlet.peersListTitle=Mine Opennet koplinger (ukjente noder 
lagt til av noden din i promisku?s modus)
OpennetUserAlert.warning=Noden din er for tiden i promisku?s modus. Den vil 
koble til Fremmede, and det betyr at alle kan finne ut at du har en node. De 
fleste angrep er lettere, blokkering av noden din (for eksempel med en nasjonal 
brannmur) er mye lettere og du har ingen kontroll over hvem noden din kopler 
til. Vi anbefaler sterkt at du skaffer deg noen koplinger til Venner (noder du 
som stoler p? og som er kontrollert av folk du allerede kjenner); promisku?s 
modus er bare ment som et midlertidig tiltak til du kan kople til vennene dine. 
Hvis du bare kopler til vennene dine er det mindre sjanse for at noden din er 
synlig for undertrykkende organisasjoner som vil kople til deg, selv vennene 
dine kan angripe deg. Merk at ? legge til en node i Venne-delen ikke hjelper 
mye hvis denne noden ikke kontrolleres av noen du faktisk kjenner (b?de for 
nettverkets- og for sikkerhetsgrunner)!
OpennetUserAlert.warningTitle=Advarsel: Promisku?s modus aktivert: Noden din 
kan koble til Fremmede
PeerManagerUserAlert.noConns=Noden din har ikke kunnet koble til noen andre 
noder s? langt; den vil ikke kunne fungere normalt. Forh?pentligvis vil noen av 
nodene koble til snart; hvis ikke, pr?v ? skaffe noen flere tilkoplinger. Du 
trenger minst 3 tilkoplinger, og b?r ha 5-10.
PeerManagerUserAlert.tooManyConns=Denne noden har for mange tilkoblinger 
(${count} > ${max}). ? legge til et stort antall noder automatisk vil ikke gi 
en 'small-world' topologi og kan skade nettverket.
PeerManagerUserAlert.tooManyDisconnectedTitle=For mange frakoplede noder
PeerManagerUserAlert.twoConns=Denne noden har bare to tilkoplinger. Du vil ikke 
f? god ytelse eller sikkerhet, og noden din hjelper bare i liten grad 
nettverket. Pr?v ? ha minst 3 (helst 5-10) tilkoplede noder til en hver tid.
PluginManager.loadedOnStartupLong=Klasse-sti

[freenet-dev] Updated Norwegian translation

[Martin Nyhus]

A few new and updated strings for the Norwegian translation
BookmarkEditorToadlet.urlDecodeError=Feil ved dekoding av URL
ConfigToadlet.possibilitiesTitle=Dine muligheter
ConnectionsToadlet.nodeStatus.BACKED OFF=OPPTATT
ConnectionsToadlet.nodeStatus.BUSY=OPPTATT
ConnectionsToadlet.nodeStatus.CLOCK PROBLEM=KLOKKEPROBLEM
ConnectionsToadlet.nodeStatus.CONNECTED=TILKOPLET
ConnectionsToadlet.nodeStatus.CONNECTION ERROR=TILKOPLINGSFEIL
ConnectionsToadlet.nodeStatus.DISABLED=DEAKTIVERT
ConnectionsToadlet.nodeStatus.DISCONNECTED=FRAKOPLET
ConnectionsToadlet.nodeStatus.DISCONNECTING=KOBLER FRA
ConnectionsToadlet.nodeStatus.LISTEN ONLY=BARE LYTT
ConnectionsToadlet.nodeStatus.LISTENING=LYTTER
ConnectionsToadlet.nodeStatus.NEVER CONNECTED=ALDRI TILKOPLET
ConnectionsToadlet.nodeStatus.TOO NEW=FOR NY
ConnectionsToadlet.nodeStatus.TOO OLD=FOR GAMMEL
ConnectionsToadlet.nodeStatus.UNKNOWN STATUS=UKJENT STATUS
DarknetConnectionsToadlet.addPeerTitle=Legg til en ny node
DarknetConnectionsToadlet.backedOff=Tilkoblet, men opptatt: Disse nodene er 
tilkoblet, men er opptatt, så noden din sender ingen forespørsler til dem.
DarknetConnectionsToadlet.busy=Opptatt: Disse nodene er tilkoblet, men for 
opptatt til å svare på våre forespørsler, så noden din sender ingen 
forespørsler til dem.
DarknetConnectionsToadlet.disabled=Ikke tilkoblet og deaktivert: Du har 
instruert noden din til ikke å koble til disse nodene.
DarknetConnectionsToadlet.listenOnly=Ikke tilkoblet og bare lytter: noden din 
vil ikke prøve å koble til disse nodene, fordi brukeren har markert de med 
BareLytt.
DarknetConnectionsToadlet.neverConnected=Aldri tilkoblet: Noden din har aldri 
koblet til disse nodene.
DarknetConnectionsToadlet.noPeersWithHomepageLink=Freenet kan ikke fungere 
ettersom du ikke har lagt til noen noder så langt. Vennligst gå til 
${link}nodens hjemmeside${/link} og les den øverste infoboksen for å se hvordan 
dette gjøres.
DarknetConnectionsToadlet.privateNote=Et privat notat om denne noden
DarknetConnectionsToadlet.removePeers=Fjern valgte noder
DarknetConnectionsToadlet.tooNew=Tilkoblet, men for ny: Disse nodenes laveste 
obligatoriske versjon er høyere enn din nodes versjonsnummer.
DarknetConnectionsToadlet.tooOld=Tilkoplet, men for gammel: Din nodes laveste 
obligatoriske versjon er høyere enn denne nodens versjonsnummer. Noden din vil 
ikke sende forespørsler til denne noden.
DarknetConnectionsToadlet.triedToAddSelf=Du kan ikke legge til din egen node 
til listen over eksterne noder.
FProxyToadlet.opennet=Administrer fremmede noder
FProxyToadlet.plugins=Administrer tillegg
MeaningfulNodeNameUserAlert.noNodeNick=Det virker som noden din ikke vet om 
pseudonymet ditt. Generelt sett er det en god ide å legge inn e-mail adressen 
din eller IRC pseudonymet ditt her så vennene dine lettere kan identifisere 
noden din (merk at bare venner kan se node-navnet ditt, det vises ikke til 
fremmede).
OpennetConnectionsToadlet.fullTitle=${counts} Fremmede (ukjente noder) 
tilkoblet ${name}
OpennetConnectionsToadlet.peersListTitle=Mine Opennet koplinger (ukjente noder 
lagt til av noden din i promiskuøs modus)
OpennetUserAlert.warning=Noden din er for tiden i promiskuøs modus. Den vil 
koble til Fremmede, and det betyr at alle kan finne ut at du har en node. De 
fleste angrep er lettere, blokkering av noden din (for eksempel med en nasjonal 
brannmur) er mye lettere og du har ingen kontroll over hvem noden din kopler 
til. Vi anbefaler sterkt at du skaffer deg noen koplinger til Venner (noder du 
som stoler på og som er kontrollert av folk du allerede kjenner); promiskuøs 
modus er bare ment som et midlertidig tiltak til du kan kople til vennene dine. 
Hvis du bare kopler til vennene dine er det mindre sjanse for at noden din er 
synlig for undertrykkende organisasjoner som vil kople til deg, selv vennene 
dine kan angripe deg. Merk at å legge til en node i Venne-delen ikke hjelper 
mye hvis denne noden ikke kontrolleres av noen du faktisk kjenner (både for 
nettverkets- og for sikkerhetsgrunner)!
OpennetUserAlert.warningTitle=Advarsel: Promiskuøs modus aktivert: Noden din 
kan koble til Fremmede
PeerManagerUserAlert.noConns=Noden din har ikke kunnet koble til noen andre 
noder så langt; den vil ikke kunne fungere normalt. Forhåpentligvis vil noen av 
nodene koble til snart; hvis ikke, prøv å skaffe noen flere tilkoplinger. Du 
trenger minst 3 tilkoplinger, og bør ha 5-10.
PeerManagerUserAlert.tooManyConns=Denne noden har for mange tilkoblinger 
(${count} > ${max}). Å legge til et stort antall noder automatisk vil ikke gi 
en 'small-world' topologi og kan skade nettverket.
PeerManagerUserAlert.tooManyDisconnectedTitle=For mange frakoplede noder
PeerManagerUserAlert.twoConns=Denne noden har bare to tilkoplinger. Du vil ikke 
få god ytelse eller sikkerhet, og noden din hjelper bare i liten grad 
nettverket. Prøv å ha minst 3 (helst 5-10) tilkoplede noder til en hver tid.
PluginManager.loadedOnStartupLong=Klasse-sti, navn og lokasjon for tillegg som 
skal

[freenet-dev] Error message

[Martin Nyhus]

Got this error message while trying to download the file below.
 
Couldn't retrieve key: [EMAIL PROTECTED]/fiw/9//fiw.zip Hops To Live: 15
Please report the following to devl@freenetproject.org: 
freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with 542793 moved.
freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with 542793 moved.at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:312)at freenet.client.GetRequestProcess.getNextRequest
(GetRequestProcess.java:74)at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)at freenet.client.AutoRequester.onReachedState
(AutoRequester.java:940)at freenet.client.AutoRequester.access$100(AutoRequester.java:32)at freenet.client.AutoRequester$AutoListener.onDone(AutoRequester.java:994)at freenet.client.listeners.DoneListener.receive
(DoneListener.java:61)at freenet.client.AutoRequester$AutoListener.receive(AutoRequester.java:990)at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java:55)at freenet.client.InternalClient$InternalFeedbackToken.unlockedProduceEvent
(InternalClient.java:192)at freenet.client.InternalClient$InternalGetToken$TransferCompleteListener.receive(InternalClient.java:319)at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java:55)
at freenet.client.SegmentOutputStream.close(SegmentOutputStream.java:227)at java.io.FilterOutputStream.close(Unknown Source)at freenet.support.io.FilterDataChunkOutputStream.close(FilterDataChunkOutputStream.java:23)
at java.io.FilterOutputStream.close(Unknown Source)at freenet.OutputStreamTrailerWriter.close(OutputStreamTrailerWriter.java:35)at freenet.node.states.data.SendData.closeSend(SendData.java:187)at freenet.node.states.data.SendData.handleThrowable
(SendData.java:419)at freenet.node.states.data.SendData.finish(SendData.java:578)at freenet.node.states.data.SendData.received(SendData.java:277)at freenet.node.StateChain.received(StateChain.java:177)at freenet.node.StateChain.received
(StateChain.java:61)at freenet.node.StateChainManagingMessageHandler$ChainContainer.run(StateChainManagingMessageHandler.java:335)at freenet.node.StateChainManagingMessageHandler$ChainContainer.received(StateChainManagingMessageHandler.java
:288)at freenet.node.StateChainManagingMessageHandler$ChainContainer.access$100(StateChainManagingMessageHandler.java:207)at freenet.node.StateChainManagingMessageHandler.handle(StateChainManagingMessageHandler.java
:99)at freenet.Ticker$Event.run(Ticker.java:325)at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.java:285)
 
Great job with Freenet
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Error message

[Martin Nyhus]

Got this error message while trying to download the file below.

Couldn't retrieve key: SSK at M7yZgrl8gwtAe1xEcR5Xyv4tFsoPAgM/fiw/9//fiw.zip
Hops To Live: 15

Please report the following to devl at freenetproject.org:


freenet.client.WrongStateException: Wrong state: FAILED should be DONE:
null: Transfer failed with 542793 moved.
freenet.client.WrongStateException: Wrong state: FAILED should be DONE:
null: Transfer failed with 542793 moved.
at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java
:312)
at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java
:74)
at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java
:324)
at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java
:74)
at freenet.client.AutoRequester.onReachedState(AutoRequester.java:940)
at freenet.client.AutoRequester.access$100(AutoRequester.java:32)
at freenet.client.AutoRequester$AutoListener.onDone(AutoRequester.java:994)
at freenet.client.listeners.DoneListener.receive(DoneListener.java:61)
at freenet.client.AutoRequester$AutoListener.receive(AutoRequester.java:990)
at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java
:55)
at freenet.client.InternalClient$InternalFeedbackToken.unlockedProduceEvent(
InternalClient.java:192)
at
freenet.client.InternalClient$InternalGetToken$TransferCompleteListener.receive
(InternalClient.java:319)
at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java
:55)
at freenet.client.SegmentOutputStream.close(SegmentOutputStream.java:227)
at java.io.FilterOutputStream.close(Unknown Source)
at freenet.support.io.FilterDataChunkOutputStream.close(
FilterDataChunkOutputStream.java:23)
at java.io.FilterOutputStream.close(Unknown Source)
at freenet.OutputStreamTrailerWriter.close(OutputStreamTrailerWriter.java
:35)
at freenet.node.states.data.SendData.closeSend(SendData.java:187)
at freenet.node.states.data.SendData.handleThrowable(SendData.java:419)
at freenet.node.states.data.SendData.finish(SendData.java:578)
at freenet.node.states.data.SendData.received(SendData.java:277)
at freenet.node.StateChain.received(StateChain.java:177)
at freenet.node.StateChain.received(StateChain.java:61)
at freenet.node.StateChainManagingMessageHandler$ChainContainer.run(
StateChainManagingMessageHandler.java:335)
at freenet.node.StateChainManagingMessageHandler$ChainContainer.received(
StateChainManagingMessageHandler.java:288)
at freenet.node.StateChainManagingMessageHandler$ChainContainer.access$100(
StateChainManagingMessageHandler.java:207)
at freenet.node.StateChainManagingMessageHandler.handle(
StateChainManagingMessageHandler.java:99)
at freenet.Ticker$Event.run(Ticker.java:325)
at freenet.thread.YThreadFactory$YThread.run(YThreadFactory.java:285)

Great job with Freenet
-- next part --
An HTML attachment was scrubbed...
URL: