ext attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/7950bb26/attachment.pgp>
s thereon: that they are
> only set if we have verified incompatibility through a handshake. In
> practice, it appears that they could still be set upon receiving a new
> reference (ark?) as well.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/e532040c/attachment.pgp>
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/e11f0e01/attachment.pgp>
e ARK even if it is
incompatible.
> (3) IP has changed, so can't handshake
> (4) wont get new IP (ark), because older version
This is the bug afaics.
>
> A better solution to this might simply be to fetch arks even on
> version incompatibility, but (for caution) behavior #2 seemed
> intentional (dont fetch ark on incompatible version), whereas #1 did
> not, and brought it closer to the comments (i.e. don't set 'verified'
> unless handshake).
I really don't see any reason not to fetch the ARK just because it was
incompatible last time. That's a bug, it's a connectivity problem.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/1a8982fc/attachment.pgp>
To be clear, a TOO OLD/TOO NEW peer is currently connected in the sense
that the node is exchanging traffic with it. The node just doesn't
route any traffic through the peer and the traffic with the peer is
limited to keeping the connectivity, N2NMs and UoM exchanges (I don't
believe I'm forgettin
In my thinking, we should only change verifiedIncompatibleOlderVersion
and verifiedIncompatibleNewerVersion in four situations, all of which
may even mean that we call a function/method to check for the need to
change in the code paths that are common to each of these situations:
1) Potentially se
On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote:
> On Wednesday 02 January 2008 17:22, Robert Hailey wrote:
>>
>> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote:
>>
> synchronized void updateShouldDisconnectNow() {
> //FIXME: We should not update VERIFIED unless we HA
Matthew Toseland wrote:
>> There's a tradeoff here: large cells provide a large anonymity set if
>> the attacker's outside the cell, but they make it more likely that
>> there's an attacker inside the cell who can attack key distribution etc.
>
> Sure, but inside the cell it's harder to attack tha
Matthew Toseland wrote:
> "Local" = direct peer. If we use one tunnel per local pseudo-identity, it
> might work, but there is still a very high chance that the node sending the
> request is the originator.
Right, but that's also the case at the moment: if requests travel n hops
on average then
Matthew Toseland wrote:
> No, but it would make the request time variance much higher, especially for
> inserts and unsuccessful requests (which can potentially visit the entire
> network).
True, the variance would be higher. Visiting the entire network is a bit
of an extreme example though - in
Matthew Toseland wrote:
> - It should be possible with such a simple request/response to make it
> extremely difficult for two nodes to realise they are on the same path,
> except in the case where they are actually adjacent.
I think that's optimistic - they could use the tunnel construction tim
previous email : from an architectural
point of view, I don't think that we should have "one" fproxy but more...
One with and one without ssl support, possibly running on different port
numbers.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/fe3274d2/attachment.pgp>
To be clear, a TOO OLD/TOO NEW peer is currently connected in the sense
that the node is exchanging traffic with it. The node just doesn't
route any traffic through the peer and the traffic with the peer is
limited to keeping the connectivity, N2NMs and UoM exchanges (I don't
believe I'm forgettin
In my thinking, we should only change verifiedIncompatibleOlderVersion
and verifiedIncompatibleNewerVersion in four situations, all of which
may even mean that we call a function/method to check for the need to
change in the code paths that are common to each of these situations:
1) Potentially se
On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote:
> On Wednesday 02 January 2008 17:22, Robert Hailey wrote:
>>
>> On Dec 29, 2007, at 5:39 AM, Florent Daignière wrote:
>>
> synchronized void updateShouldDisconnectNow() {
> //FIXME: We should not update VERIFIED unless we HA
On Sunday 30 December 2007 13:27, Michael Rogers wrote:
> Matthew Toseland wrote:
> > If you route randomly on each hop I'd
> > expect to on average not get very far, because *most links are short
links*
> > on a small-world network.
>
> Yup, it's counter-intuitive because of clustering but sma
On Sunday 30 December 2007 13:19, Michael Rogers wrote:
>
> >> This could actually be used in place of premix routing: instead of
> >> constructing cells we use random "tunnel IDs".
> >
> > No use against a local attacker.
>
> What kind of attack do you have in mind?
"Local" = direct peer. If
On Sunday 30 December 2007 13:19, Michael Rogers wrote:
> Matthew Toseland wrote:
> > - Not compatible afaics with ULPRs / failure tables. ULPRs stop requests
if
> > we've routed them already (for some period), with the same HTL or less.
>
> Good point, and I guess the same would be true of requ
On Sunday 30 December 2007 13:19, Michael Rogers wrote:
> > The idea was to pick two random nodes from within the cell, and route
through
> > them - choosing a new tunnel for every request.
>
> Why choose a new tunnel for every request? If an attacker inside the
> cell can somehow link messages
are calling it from PacketSender
> >
> > What about getting rid of both the "if" branch and the call in
> > PacketSender ?
>
> Why not just use if(isConnected()) { ... } ? As far as I can see that is
> correct: if we're not connected, we don't care about verified*.
You're suggesting to revert robert's patch, wich is fine by me... as I
said, I don't understand why it helps
NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/2e8eff83/attachment.pgp>
On Wednesday 02 January 2008 17:22, Robert Hailey wrote:
>
> On Dec 29, 2007, at 5:39 AM, Florent Daignière wrote:
>
> >>> synchronized void updateShouldDisconnectNow() {
> >>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH
> >>>
> >>> THE NODE
> >>> - if (
On Wednesday 02 January 2008 18:30, David Sowder wrote:
> I'm not sure of the thinking of others regarding changes to the
> verifiedIncompatible variables since, but my thinking in my initial
> implementation was that they would only be set after a handshake, thus
> we already had a connected to
On Wednesday 02 January 2008 18:15, Robert Hailey wrote:
>
> On Jan 2, 2008, at 7:38 AM, Florent Daignière wrote:
>
> > synchronized void updateShouldDisconnectNow() {
> > //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH
> >
> > THE NODE
> > - i
"if" branch and the call in
> PacketSender ?
Why not just use if(isConnected()) { ... } ? As far as I can see that is
correct: if we're not connected, we don't care about verified*.
>
> NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/60d9ba92/attachment.pgp>
david at sowder.com http://david.sowder.com/
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/3e810fe1/attachment.pgp>
;t suppose you'd be interested in
getting that working?
>
> NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/b3dca549/attachment.pgp>
I'm not sure of the thinking of others regarding changes to the
verifiedIncompatible variables since, but my thinking in my initial
implementation was that they would only be set after a handshake, thus
we already had a connected to them and ARKs weren't needed. That won't
change until the pee
ompatible (but before r16834, would
set 'verified')
(2) attempt handshakes, but don't fetch ark
(3) IP has changed, so can't handshake
(4) wont get new IP (ark), because older version
A better solution to this might simply be to fetch arks even on
version incompatibilit
problem
>> -Logger.error(this, "Timeout (" + next + ") after Accepted in
>> insert");
>> +Logger.error(this, "Timeout (" + msg + ") after Accepted in
>> insert; to ("+next+")");
-- next part --
A
ars that they could still be set upon receiving a new
reference (ark?) as well.
--
Robert Hailey
-- next part --
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080102/0836e813/attachment.html>
I'm not sure of the thinking of others regarding changes to the
verifiedIncompatible variables since, but my thinking in my initial
implementation was that they would only be set after a handshake, thus
we already had a connected to them and ARKs weren't needed. That won't
change until the pee
On Jan 2, 2008, at 7:38 AM, Florent Daignière wrote:
synchronized void updateShouldDisconnectNow() {
//FIXME: We should not update VERIFIED unless we HANDSHAKE WITH
THE NODE
- if (isConnected()) {
+ if (isConnected() || verifiedIncompatibleOlderVersion ||
verifiedIncompatibleNewerVe
On Jan 2, 2008, at 6:57 AM, Matthew Toseland wrote:
On Tuesday 01 January 2008 15:23, David Sowder wrote:
Do we want to print the null?
Probably a good idea.
It does seem kind of weird perhaps (as msg will always be null), but
it makes the logging match that in CHKInsertSender, and when
On Dec 29, 2007, at 5:39 AM, Florent Daignière wrote:
synchronized void updateShouldDisconnectNow() {
//FIXME: We should not update VERIFIED unless we HANDSHAKE WITH
THE NODE
- if (isConnected()) {
+ if (isConnected() || verifiedIncompatibleOlderVersion ||
verified
* Matthew Toseland <[EMAIL PROTECTED]> [2008-01-02 12:56:11]:
> On Tuesday 25 December 2007 01:19, Florent Daigni?re wrote:
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-12-22 00:12:28]:
> >
> > > Author: toad
> > > Date: 2007-12-22 00:12:28 + (Sat, 22 Dec 2007)
> > > New Revision: 16775
Ian: example of why we need DVCS IMHO. I committed a patch from ET on Frost,
because I want anonymous contributors, and to encourage a new dev. I did a
basic code review (and gave input on architecture, this is the second patch
to be committed), now nextgens is quibbling about it...
On Tuesday
* Matthew Toseland <[EMAIL PROTECTED]> [2008-01-02 12:58:45]:
> On Saturday 29 December 2007 11:39, Florent Daignière wrote:
> > * Florent Daignière <[EMAIL PROTECTED]> [2007-12-29 12:05:17]:
> >
> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-12-29
> 01:46:31]:
> > >
> > > > Author: robert
On Saturday 29 December 2007 11:39, Florent Daignière wrote:
> * Florent Daignière <[EMAIL PROTECTED]> [2007-12-29 12:05:17]:
>
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-12-29
01:46:31]:
> >
> > > Author: robert
> > > Date: 2007-12-29 01:46:31 + (Sat, 29 Dec 2007)
> > > New Revision:
On Tuesday 01 January 2008 15:23, David Sowder wrote:
> Do we want to print the null?
Probably a good idea.
>
> [EMAIL PROTECTED] wrote:
> > Author: robert
> > Date: 2007-12-28 16:50:28 + (Fri, 28 Dec 2007)
> > New Revision: 16825
> >
> > Modified:
> >trunk/freenet/src/freenet/node/SSKIns
39 matches
Mail list logo
