From 13b38463ab46a8535d95b1ca41acf94c999d7d0b Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 29 May 2015 16:05:36 +0000 Subject: [PATCH 001/114] First pass at redesigning content layout --- i2p2www/pages/global/layout.html | 23 ++++++--- i2p2www/static/styles/duck/default.css | 70 +++++++++++++++++--------- i2p2www/static/styles/duck/desktop.css | 28 +++++------ i2p2www/static/styles/duck/mobile.css | 6 ++- 4 files changed, 79 insertions(+), 48 deletions(-) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index afda10c3..0239bd0e 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -49,7 +49,18 @@
{% block content_outer %} -
+
+

{{ self.title() }}

+
+ +
+
-
+
+
{% if self.content_nav() or self.sidebar() or self.lastupdated() or self.accuratefor() -%} {%- endif %} -
+
{% block content %}{% endblock %}
+
{% endblock %}
diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css index 23112796..7c69bfc0 100644 --- a/i2p2www/static/styles/duck/default.css +++ b/i2p2www/static/styles/duck/default.css @@ -156,12 +156,11 @@ div#content .feed-icon { div#content .inner { background: rgba(0, 0, 0, 0.05); - width: auto; - padding: 0 5% 0.1em; - position: relative; border-top: 2px solid #abcc71; color: black; line-height: 1.5em; + position: relative; + width: auto; } div#content .inner:before { @@ -174,11 +173,15 @@ div#content .inner:before { width: 100%; } +div#content .inner .fluid { + background: white; + border-left: 2px solid #abcc71; + border-right: 2px solid #abcc71; +} + div#content .sidebar { background: rgba(171, 204, 113, 0.6); border-bottom: 2px solid #abcc71; - border-left: 2px solid #abcc71; - border-right: 2px solid #abcc71; font-size: 0.875rem; } @@ -208,9 +211,6 @@ div#content .lastupdated { } div#content .content-inner { - background: white; - border-left: 2px solid #abcc71; - border-right: 2px solid #abcc71; padding: 1em 2em; } diff --git a/i2p2www/static/styles/duck/desktop.css b/i2p2www/static/styles/duck/desktop.css index 7901b5ae..cee68eaa 100644 --- a/i2p2www/static/styles/duck/desktop.css +++ b/i2p2www/static/styles/duck/desktop.css @@ -239,26 +239,23 @@ div#content .aside:first-child { * The .inner class is for the content wrapper on inner pages (as opposed to the home page) */ -div#content .inner { - padding: 0 20%; -} - -div#content .inner.two-col { - padding: 0 15% 0 10%; +div#content .inner .fluid { + margin: 0 30% 0 0.625rem; } div#content .inner .sidebar { - border-radius: 0 0 0 10px; + border-radius: 0 0 10px 0; + border-right: 2px solid #abcc71; float: left; width: 250px; } div#content .lastupdated { - border-radius: 0 0 0 10px; + border-radius: 0 0 10px 0; text-align: right; } -div#content .content-inner.two-col { +div#content .content-inner { margin-left: 252px; } From dfdb1aa7ccb3c292dc60128978a91917f7f104bb Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 31 May 2015 01:24:23 +0000 Subject: [PATCH 020/114] Create meta class for showing metadata in right margin --- i2p2www/pages/blog/post.html | 9 ++++----- i2p2www/pages/global/layout.html | 10 +++++----- i2p2www/static/styles/duck/default.css | 9 +++++++-- i2p2www/static/styles/duck/desktop.css | 10 +++++++--- 4 files changed, 23 insertions(+), 15 deletions(-) diff --git a/i2p2www/pages/blog/post.html b/i2p2www/pages/blog/post.html index ce6d9f52..484127a3 100644 --- a/i2p2www/pages/blog/post.html +++ b/i2p2www/pages/blog/post.html @@ -1,15 +1,14 @@ {% extends "global/layout.html" %} {%- from "global/macros" import render_categories with context -%} {% block title %}{{ title }} - {{ _('Blog') }}{% endblock %} -{% block sidebar %} -

From cdfcf23e60bda5afb344f3a63cb6c77b081c8390 Mon Sep 17 00:00:00 2001 From: zzz Date: Thu, 26 Nov 2015 14:31:47 +0000 Subject: [PATCH 036/114] SAM: Fix docs for STREAM ACCEPT when SILENT=true Clarify that FORWARD works differently than ACCEPT and CONNECT when SILENT=true cleanups --- i2p2www/pages/site/docs/api/samv3.html | 72 ++++++++++++++++---------- 1 file changed, 44 insertions(+), 28 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 60f6f53f..ec1d76e0 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -170,11 +170,11 @@ As of version 3.1 (I2P 0.9.14), the MIN and MAX parameters are optional. SAM will always return the highest version possible given the MIN and MAX constraints, or 3.1 if no constraints are given. -If the SAM bridge cannot find a suitable version, it replies with : +If the SAM bridge cannot find a suitable version, it replies with: 
 <- HELLO REPLY RESULT=NOVERSION
-If some error occurred, such as a bad request format, it replies with : +If some error occurred, such as a bad request format, it replies with: 
 <- HELLO REPLY RESULT=I2P_ERROR MESSAGE=$message
@@ -191,7 +191,7 @@ Each registered I2P Destination is uniquely associated with a session ID (or nickname).

-Each session is uniquely associated with : +Each session is uniquely associated with:

  • the socket from which the client creates the session
  • @@ -247,7 +247,7 @@ After receiving the session create message, the SAM bridge will reply with a session status message, as follows:

    -If the creation was successful : +If the creation was successful: 

     <-  SESSION STATUS RESULT=OK DESTINATION=$privkey
    @@ -261,25 +261,25 @@ depending on signature type. The binary format is specified in Private Key File.

    -If the nickname is already associated with a session : +If the nickname is already associated with a session: 

     <-  SESSION STATUS RESULT=DUPLICATED_ID

    -If the destination is already in use : +If the destination is already in use: 

     <-  SESSION STATUS RESULT=DUPLICATED_DEST

    -If the destination is not a valid private destination key : +If the destination is not a valid private destination key: 

     <-  SESSION STATUS RESULT=INVALID_KEY

    -If some other error has occurred : +If some other error has occurred: 

     <-  SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message
    @@ -313,13 +313,13 @@ he wants to listen to requests coming from other I2P destinations.

    SAM Virtual Streams : CONNECT

    -A client asks for a connection by : +A client asks for a connection by:

    • opening a new socket with the SAM bridge
    • passing the same HELLO handshake as above
    • -sending the connection command : +sending the STREAM CONNECT command: 
    @@ -340,7 +340,7 @@ depending on signature type.
 
 
    
 If SILENT=true is passed, the SAM bridge won't issue any other message
-on the socket : if the connection fails, the socket will be closed.
+on the socket. If the connection fails, the socket will be closed.
 If the connection succeeds, all remaining data passing through the
 current socket is forwarded from and to the connected I2P destination
 peer.
@@ -348,7 +348,7 @@ peer.
 
    
 If SILENT=false, which is the default value, the SAM bridge sends a
 last message to its client before forwarding or shutting down the
-socket :
+socket:
 
 
     <-  STREAM STATUS 
@@ -379,13 +379,13 @@ socket.
 
 
    SAM Virtual Streams : ACCEPT
    
 
    
-A client waits for an incoming connection request by :
+A client waits for an incoming connection request by:
 
    • 
 opening a new socket with the SAM bridge
 
    • 
 passing the same HELLO handshake as above
 
    • 
-sending the accept command :  
+sending the STREAM ACCEPT command:  
 
    
 
 
    @@ -399,7 +399,18 @@ This makes the session ${nickname} listen for one incoming
 connection request from the I2P network.
 
 
    
-The SAM bridge answers with :
+If SILENT=true is passed, the SAM bridge won't issue any other message
+on the socket. If the accept fails, the socket will be closed.
+If the accept succeeds, all remaining data passing through the
+current socket is forwarded from and to the connected I2P destination
+peer. 
+For reliability, and to receive the destination for incoming connections,
+SILENT=false is recommended.
+
+
+
    
+If SILENT=false, which is the default value,
+the SAM bridge answers with:
 
 
     <-  STREAM STATUS 
@@ -420,11 +431,11 @@ The RESULT value may be one of:
 If the result is not OK, the socket is closed immediately by the SAM
 bridge. If the result is OK, the SAM bridge starts waiting for an
 incoming connection request from another I2P peer. When a request
-arrives, the SAM bridge accepts it and :
+arrives, the SAM bridge accepts it and:
 
 
    
 If SILENT=true was passed, the SAM bridge won't issue any other message
-on the client socket : all remaining data passing through the
+on the client socket. All remaining data passing through the
 current socket is forwarded from and to the connected I2P destination
 peer.
 
@@ -439,13 +450,13 @@ I2P destination peer, until one of the peer closes the socket.
 
    SAM Virtual Streams : FORWARD
    
 
    
 A client can use a regular socket server and wait for connection requests
-coming from I2P. For that, the client has to :
+coming from I2P. For that, the client must:
 
    • 
 open a new socket with the SAM bridge
 
    • 
 pass the same HELLO handshake as above
 
    • 
-send the forward command :
+send the forward command:
 
    • @@ -461,7 +472,12 @@ This makes the session ${nickname} listen for incoming
 connection requests from the I2P network.
 
 
    
-The SAM bridge answers with :
+SILENT defaults to false.
+Whether SILENT is true or false,
+the SAM bridge always answers with a STREAM STATUS message.
+Note that this is a different behavior from STREAM ACCEPT and STREAM CONNECT
+when SILENT=true.
+The STREAM STATUS message is:
 
 
     <-  STREAM STATUS 
@@ -490,7 +506,7 @@ forward connection requests. It is mandatory.
 
    
 When a connection request arrives from I2P, the SAM bridge requests a
 socket connection from $host:$port. If it is accepted after no more
-than 3 seconds, SAM will accept the connection from I2P, and then :
+than 3 seconds, SAM will accept the connection from I2P, and then:
 
 
    
 If SILENT=true was passed, all data passing through the obtained
@@ -532,8 +548,8 @@ After establishing a SAM session with STYLE=DATAGRAM, the client can
 send datagrams through SAM's UDP port (7655).
 
 
    
-The first line of a datagram sent through this port has to be in the
-following format :
+The first line of a datagram sent through this port must be in the
+following format:
 
 
    
 3.0 $nickname $destination
@@ -553,7 +569,7 @@ following format :
 
 
    
 The first line will be discarded by SAM before sending the remaining
-of the message to the specified destination.
+data of the message to the specified destination.
 
 
    
 For an alternate method of sending repliable datagrams, see DATAGRAM SEND.
@@ -567,7 +583,7 @@ command.
 
 
    
 When a datagram arrives, the bridge delivers it to the client via the
-message :
+message:
 
 
     <-  DATAGRAM RECEIVED
@@ -590,7 +606,7 @@ connection).
 
    
 When creating a datagram session, the client can ask SAM to forward
 incoming messages to a specified ip:port. It does so by issuing the
-CREATE command with PORT and HOST options :
+CREATE command with PORT and HOST options:
 
 
     -> SESSION CREATE 
@@ -628,7 +644,7 @@ outbound.length=0). These options are documented below..
 Forwarded datagrams are always prefixed with the destination
 (SILENT=false); SILENT=true is not honored.
 When a datagram arrives, the bridge sends to the specified host:port
-a UDP packet containing the following data :
+a UDP packet containing the following data:
 
 
     $destination\n$datagram_payload
@@ -673,7 +689,7 @@ the session,the bridge delivers it to the client via:
 
    
 When anonymous datagrams are to be forwarded to some host:port,
 the bridge sends to the specified host:port a message containing 
-the following data :
+the following data:
 
 
     $datagram_payload

From 69df0b34c326550ba6bc45821021e04fdd429886 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Fri, 27 Nov 2015 18:25:52 +0000
Subject: [PATCH 037/114] SAM: Add docs for RAW forwarding, previously
 undocumented Clarify RAW and DATAGRAM handling when PORT not specified (v1/v2
 mode) Add HEADER to get a header with RAW forwarding in 3.2

---
 i2p2www/pages/site/docs/api/samv3.html | 45 ++++++++++++++++++--------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index ec1d76e0..deede231 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -59,10 +59,12 @@ Version 3.2 is not yet implemented, and the changes listed below are preliminary
 
  • SESSION CREATE STYLE=RAW now supports option PROTOCOL=nnn to set default I2P protocol (18 otherwise)
 
  • STREAM CONNECT, DATAGRAM SEND, and RAW SEND now support new options FROM_PORT=nnnn and TO_PORT=nnnn
     to override default I2P ports for that connection
-
  • STREAM ACCEPT now supports option TO_PORT=nnnn to accept connections on that I2P port only
 
  • RAW SEND now supports option PROTOCOL=nnn to override default I2P RAW protocol value (18)
-
  • DATAGRAM RECEIVED, RAW RECEIVED, and forwarded or received streams and datagrams, when SILENT=false,
+
  • DATAGRAM RECEIVED, RAW RECEIVED, and forwarded or received streams and repliable datagrams,
     now appends to the first line is FROM_PORT=nnnn TO_PORT=nnnn to indicate I2P ports
+
  • For a RAW session forwarded to an external port, if the option HEADER=true is provided,
+    the forwarded raw datagram will be prepended with a line containing PROTOCOL=nnn FROM_PORT=nnnn TO_PORT=nnnn
+    The line ends with \n.
 
  • The first line of datagrams sent through port 7655 may now start with any 3.x version
 
  • The first line of datagrams sent through port 7655 may have, after the destination,
     any of the options FROM_PORT=nnnn TO_PORT=nnnn PROTOCOL=nnn
@@ -100,6 +102,7 @@ Version 3.3 is not yet implemented, and the changes listed below are preliminary
 
      
 
    • The same session ID may be used for streams, datagrams, and raw simultaneously.
     Incoming packets and streams will be routed based on I2P protocol and to-port.
+
    • STREAM ACCEPT now supports option TO_PORT=nnnn to accept connections on that I2P port only
 
    
 
    
 
@@ -578,8 +581,8 @@ For an alternate method of sending repliable datagrams, see DA
 
    SAM Repliable Datagrams : Receiving a Datagram
    
 
    
 Received datagrams are written by SAM on the socket from which the
-datagram session was opened, unless specified otherwise by the CREATE
-command.
+datagram session was opened, if a forwarding PORT is not specified in the SESSION CREATE
+command. This is the v1/v2-compatible way of receiving datagrams.
 
 
    
 When a datagram arrives, the bridge delivers it to the client via the
@@ -588,7 +591,8 @@ message:
 
     <-  DATAGRAM RECEIVED
            DESTINATION=$destination
-           SIZE=$numBytes\n[$numBytes of data]
+           SIZE=$numBytes\n
+       [$numBytes of data]
 
    
 
 
    
@@ -602,7 +606,7 @@ or other fields, merely the data that the sender provided.  This
 continues until the session is closed (by the client dropping the
 connection).
 
-
    SAM Repliable Datagrams : Forwarding Datagrams
    
+
    SAM Datagrams : Forwarding Raw or Repliable Datagrams
    
 
    
 When creating a datagram session, the client can ask SAM to forward
 incoming messages to a specified ip:port. It does so by issuing the
@@ -610,7 +614,7 @@ CREATE command with PORT and HOST options:
 
 
     -> SESSION CREATE 
-          STYLE=DATAGRAM
+          STYLE={DATAGRAM,RAW}
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
           PORT=$port
@@ -634,6 +638,8 @@ CREATE command with PORT and HOST options:
 
    
  $port is the port number of the datagram server to which SAM
      will forward datagrams.
+ If $port is not set, datagrams will NOT be forwarded, they will be received on the control socket,
+ in the v1/v2-compatible way.
 
 
    
 Additional options given are passed to the I2P session 
@@ -641,13 +647,22 @@ configuration if not interpreted by the SAM bridge (e.g.
 outbound.length=0). These options are documented below..
 
 
    
-Forwarded datagrams are always prefixed with the destination
-(SILENT=false); SILENT=true is not honored.
-When a datagram arrives, the bridge sends to the specified host:port
+Forwarded repliable datagrams are always prefixed with the destination.
+When a repliable datagram arrives, the bridge sends to the specified host:port
 a UDP packet containing the following data:
 
 
    -$destination\n$datagram_payload
+$destination\n
+$datagram_payload
+
    
+
+
    
+Forwarded raw datagrams are forwarded as-is
+to the specified host:port without a prefix.
+The UDP packet contains the following data:
+
+
    +$datagram_payload
 
    
 
 
    
@@ -678,12 +693,14 @@ Both ways of receiving datagrams are also available for anonymous
 datagrams.
 
 
    
-When anonymous datagrams are to be written to the socket that created
-the session,the bridge delivers it to the client via:
+Received datagrams are written by SAM on the socket from which the
+datagram session was opened, if a forwarding PORT is not specified in the SESSION CREATE
+command. This is the v1/v2-compatible way of receiving datagrams.
 
 
     <- RAW RECEIVED
-      SIZE=$numBytes\n[$numBytes of data]
+          SIZE=$numBytes\n
+      [$numBytes of data]
 
    
 
 
    

From 514f07041cb26af6155b303b29d5a2656be54163 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Fri, 27 Nov 2015 18:52:55 +0000
Subject: [PATCH 038/114] defer advanced datagram options to 3.3

---
 i2p2www/pages/site/docs/api/samv3.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index deede231..2059dd3f 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -69,9 +69,6 @@ Version 3.2 is not yet implemented, and the changes listed below are preliminary
 
  • The first line of datagrams sent through port 7655 may have, after the destination,
     any of the options FROM_PORT=nnnn TO_PORT=nnnn PROTOCOL=nnn
 
  • RAW RECEIVED now appends to the first line PROTOCOL=nnn to indicate I2P protocol
-
  • DATAGRAM SEND and RAW SEND now supports options SEND_TAGS=nnn, TAG_THRESHOLD=nnn, EXPIRES=nnnnnnn, and SEND_LEASESET=true|false.
-    These will be passed to I2CP if supported. See the I2CP specification for details.
-    Support by the SAM server is optional, it will ignore these options if unsupported.
 
  • Client and server may now send: PING [arbitrary text] on the control port,
     with the response:
     PONG [arbitrary text from the ping], to be used for control socket keepalive.
@@ -103,6 +100,9 @@ Version 3.3 is not yet implemented, and the changes listed below are preliminary
 
  • The same session ID may be used for streams, datagrams, and raw simultaneously.
     Incoming packets and streams will be routed based on I2P protocol and to-port.
 
  • STREAM ACCEPT now supports option TO_PORT=nnnn to accept connections on that I2P port only
+
  • DATAGRAM SEND and RAW SEND now supports options SEND_TAGS=nnn, TAG_THRESHOLD=nnn, EXPIRES=nnnnnnn, and SEND_LEASESET=true|false.
+    These will be passed to I2CP if supported. See the I2CP specification for details.
+    Support by the SAM server is optional, it will ignore these options if unsupported.

From ae1bc10ff33f940c26a9aadeae8821076cab0a7b Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 27 Nov 2015 19:43:12 +0000 Subject: [PATCH 039/114] clarify that parallel ACCEPTs were not allowed prior to 3.2 --- i2p2www/pages/site/docs/api/samv3.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 2059dd3f..1e9d4df0 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -83,7 +83,7 @@ Version 3.2 is not yet implemented, and the changes listed below are preliminary
  • AUTH REMOVE USER=foo removes this user
  • Multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port). - It isn't clear (either in the spec or the code) if these are allowed now. + Prior to 3.2, concurrent accepts would fail with ALREADY_ACCEPTING.
  • The server's control socket may optionally offer SSL/TLS support, as configured on the server and client. Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.
  • For STREAM FORWARD, client may add SSL=true to use an SSL socket From 8747e9b93ceafdc82d03c2f7ab301e0d70f6ad65 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 28 Nov 2015 21:42:00 +0000 Subject: [PATCH 040/114] SAM: Document command line parsing enhancements (ticket #1488) --- i2p2www/pages/site/docs/api/samv3.html | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 1e9d4df0..0f86f2c5 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -53,7 +53,8 @@ Version 3.1 was introduced in I2P release 0.9.14.

    Version 3.2 Proposal

    -Version 3.2 is not yet implemented, and the changes listed below are preliminary. +Version 3.2 is scheduled for inclusion in I2P release 0.9.24, and the changes listed below are preliminary. +The following changes will be incorporated in the main part of this document soon.

    • SESSION CREATE now supports options FROM_PORT=nnnn and TO_PORT=nnnn to set default I2P ports
    • SESSION CREATE STYLE=RAW now supports option PROTOCOL=nnn to set default I2P protocol (18 otherwise) @@ -73,21 +74,33 @@ Version 3.2 is not yet implemented, and the changes listed below are preliminary with the response: PONG [arbitrary text from the ping], to be used for control socket keepalive. Either side may close the session and socket if no response is received in a reasonable time, implementation dependent. -
    • For authorization, client adds USER=xxx PASSWORD=yyy to the HELLO parameters. +
    • For authorization, client adds USER="xxx" PASSWORD="yyy" to the HELLO parameters. + Double quotes for user and password are recommended but not required. + A double quote inside a user or password must be escaped with a backslash. On failure the server will reply with an I2P_ERROR and a message. -
    • (optional feature) Authorization configuration with the AUTH command: +
    • (optional feature) Authorization configuration with the AUTH command. + A SAM server may implement these commands to facilite persistent storage of credentials.
      • AUTH ENABLE enables authorization on subsequent connections
      • AUTH DISABLE disables authorization on subsequent connections -
      • AUTH ADD USER=foo PASSWORD=bar adds a user/password -
      • AUTH REMOVE USER=foo removes this user +
      • AUTH ADD USER="foo" PASSWORD="bar" adds a user/password +
      • AUTH REMOVE USER="foo" removes this user
      + Double quotes for user and password are recommended but not required. + A double quote inside a user or password must be escaped with a backslash. + On failure the server will reply with an I2P_ERROR and a message.
    • Multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port). Prior to 3.2, concurrent accepts would fail with ALREADY_ACCEPTING.
    • The server's control socket may optionally offer SSL/TLS support, as configured on the server and client. Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.
    • For STREAM FORWARD, client may add SSL=true to use an SSL socket
    • New commands QUIT, STOP and EXIT will close the session and socket +
    • Command parsing will properly handle UTF-8 +
    • Command parsing reliably handles whitespace inside quotes +
    • A backslash '\' may escape quotes on the command line +
    • It is recommended but not required that the server map commands and option names to upper case. +
    • Empty option values such as PROTOCOL or PROTOCOL= may be allowed, implementation dependent. +
    • Servers may implement timeouts for the HELLO or subsequent commands, implementation dependent.

    From 7c305b511f049a6bb28f3a963479089ef15e1f8e Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 29 Nov 2015 20:56:15 +0000 Subject: [PATCH 041/114] Style fixes --- i2p2www/static/styles/duck/default.css | 1 - i2p2www/static/styles/duck/desktop.css | 5 ++++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css index bbbac192..094fb3c9 100644 --- a/i2p2www/static/styles/duck/default.css +++ b/i2p2www/static/styles/duck/default.css @@ -212,7 +212,6 @@ div#content .inner .box { } div#content .inner .meta { - clear: both; text-align: center; } diff --git a/i2p2www/static/styles/duck/desktop.css b/i2p2www/static/styles/duck/desktop.css index dc992c98..89a11979 100644 --- a/i2p2www/static/styles/duck/desktop.css +++ b/i2p2www/static/styles/duck/desktop.css @@ -247,12 +247,15 @@ div#content .inner .fluid { } div#content .inner .sidebar { - border-radius: 0 0 10px 0; border-right: 1px solid #abcc71; float: left; width: 250px; } +div#content .inner .sidebar, div#content .inner .sidebar > nav { + border-radius: 0 0 10px 0; +} + div#content .content-inner { margin-left: 252px; padding-right: 4em; From 0e3f00543dd776f4accc79dc03e612ba63be211a Mon Sep 17 00:00:00 2001 From: kytv Date: Mon, 30 Nov 2015 13:17:35 +0000 Subject: [PATCH 042/114] fix link to monero --- i2p2www/pages/site/get-involved/donate.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/get-involved/donate.html b/i2p2www/pages/site/get-involved/donate.html index c93ccc9b..b346ab8b 100644 --- a/i2p2www/pages/site/get-involved/donate.html +++ b/i2p2www/pages/site/get-involved/donate.html @@ -73,10 +73,10 @@ mentioned on the I2P webpage. ANC donation QR code
    -

    Monero

    +

    Monero

    {% trans date='Nov 2015', cointype='Monero', - coinurl='https://getmonero.com', + coinurl='https://getmonero.org', account='42oAxV3DVXXG3HhyCyi2xaPukKXbip9Sx1YuJtoCqjZRSze4tYCq7n3VUswDBFV59Zev8yfHSZro4TUwXumtRWnQ8xQipkC' -%} As of {{ date }}, echelon has been running a {{ cointype }} account for the I2P project. From ccaed060186bf9b243a4b71dba8d8af3cf6ac585 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 30 Nov 2015 20:22:12 +0000 Subject: [PATCH 043/114] Use a warmer white for the main bg --- i2p2www/static/styles/duck/default.css | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css index 094fb3c9..cf9ea986 100644 --- a/i2p2www/static/styles/duck/default.css +++ b/i2p2www/static/styles/duck/default.css @@ -175,7 +175,7 @@ div#content .inner:before { } div#content .inner .fluid { - background-color: white; + background-color: #fefff1; } div#content .sidebar { From 0fcceb0b0dfc38ea7d548b665a265bd0119d7311 Mon Sep 17 00:00:00 2001 From: echelon2 Date: Tue, 1 Dec 2015 16:50:18 +0000 Subject: [PATCH 044/114] updated hall of fame by 1st dec 2015 --- i2p2www/pages/site/about/hall-of-fame.html | 144 ++++++++++++++++++++- 1 file changed, 140 insertions(+), 4 deletions(-) diff --git a/i2p2www/pages/site/about/hall-of-fame.html b/i2p2www/pages/site/about/hall-of-fame.html index 1ff2afc5..ebbfabdf 100644 --- a/i2p2www/pages/site/about/hall-of-fame.html +++ b/i2p2www/pages/site/about/hall-of-fame.html @@ -1,12 +1,12 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Hall Of Fame') }}{% endblock %} {% block content %} - -{% trans date='2014-12-23' -%} + +{% trans date='2015-12-01' -%} Current balance: as of {{ date }} {%- endtrans %}
    {{ _('General fund') }}: -{% trans euroval='44644,32', btcval='537,72784571' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    +{% trans euroval='38828,28', btcval='516,95196524' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    {{ _('Datastorage bounty') }}: {% trans euroval='145.0', btcval='2' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    {{ _('I2PHex bounty') }}: @@ -45,6 +45,136 @@ with your name or nick (and optionally homepage) so we can list you here.
    +{{ _('2015 donations and costs:') }}
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    datewhoincomeoutgoingaccount
    Jan, 2015donation569 €Sponge
    Jan, 2015anonymous90 €General fund
    Jan, 2015Support Meeh500 €general fund
    Jan, 2015Support echelon300 €general fund
    Jan, 2015EUServ Rootserver660 €general fund
    Jan, 2015zzz Win 8.1 laptop210,13 €general fund
    Jan, 2015anonymous0.04 BTCGeneral fund
    Jan, 2015KyTv services2.8 BTCGeneral fund
    Jan, 2015dg services0.4 BTCGeneral fund
    Feb, 2015donation JJE50 €General fund
    Feb, 2015Sending Stickers21,80 €general fund
    Feb, 2015JULLIAN David10 €General fund
    Feb, 2015anonymous0,89 €General fund
    Feb, 2015donation anonotaku1810,51 €General fund
    Feb, 2015anonymous0.05 BTCGeneral fund
    Mar, 2015JULLIAN David10 €General fund
    Mar, 2015Domain i2pproject.net11,9 €general fund
    Mar, 2015Domain i2pproject,syndie59,5 €general fund
    Mar, 2015anonymous70 €General fund
    Mar, 2015Support Postman500 €general fund
    Mar, 2015anonymous3 €General fund
    Mar, 2015anonymous0.01 BTCGeneral fund
    Apr, 2015JULLIAN David10 €General fund
    Apr, 2015Alex10 €General fund
    Apr, 2015anonymous10 €General fund
    Apr, 2015Sending Stickers9,90 €general fund
    Apr, 2015anonymous5 €General fund
    Apr, 2015anonymous3 €General fund
    Apr, 2015Hottuna Rasperry Pi 256 €general fund
    Apr, 2015anonymous0.1 BTCGeneral fund
    Apr, 2015anonymous0.0773 BTCGeneral fund
    Apr, 2015dg Rasperry Pi 20.25 BTCGeneral fund
    May, 2015JULLIAN David10 €General fund
    May, 2015Alex10 €General fund
    May, 2015Leonardo14 €General fund
    May, 2015anonymous15 €General fund
    May, 2015anonymous3 €General fund
    May, 2015anonymous10 €General fund
    May, 2015pcboy15 €General fund
    May, 2015anonymous0.00325375 BTCGeneral fund
    Jun, 2015Sending Stickers21,80 €general fund
    Jun, 2015JULLIAN David10 €General fund
    Jun, 2015Alex10 €General fund
    Jun, 2015Stian Berger60 €General fund
    Jun, 2015Sending Stickers21,80 €general fund
    Jun, 2015TShirts I2P Con Toronto 2015162 €general fund
    Jun, 2015anonymous3 €General fund
    Jun, 2015Alex10 €General fund
    Jun, 2015anonymous3 €General fund
    Jun, 2015travel support kytv6 BTCGeneral fund
    Jun, 2015travel support cacapo1 BTCGeneral fund
    Jun, 2015anonymous0.0488 BTCGeneral fund
    Jul, 2015JULLIAN David10 €General fund
    Jul, 2015anonymous3 €General fund
    Jul, 2015anonymous0.00485993 BTCGeneral fund
    Jul, 2015travel support psi1.5 BTCGeneral fund
    Jul, 2015anonymous0.00581971 BTCGeneral fund
    Jul, 2015anonymous0.04 BTCGeneral fund
    Jul, 2015anonymous0.00839704 BTCGeneral fund
    Jul, 2015anonymous0.01884516 BTCGeneral fund
    Jul, 2015anonymous0.01714 BTCGeneral fund
    Jul, 2015anonymous0.005 BTCGeneral fund
    Jul, 2015anonymous0.01701606 BTCGeneral fund
    Aug, 2015Alex10 €General fund
    Aug, 2015JULLIAN David10 €General fund
    Aug, 2015anonymous15 €General fund
    Aug, 2015stickers10 €General fund
    Aug, 2015anonymous15 €General fund
    Aug, 2015stickers10 €General fund
    Aug, 2015anonymous20 €General fund
    Aug, 2015stickers19 €General fund
    Aug, 2015MC Red costs33 €general fund
    Aug, 2015MC Red filling cost11,40 €general fund
    Aug, 2015Toronto I2Pcon costs400 €general fund
    Aug, 2015Toronto MC Red costs553,62 €general fund
    Aug, 2015Toronto travel support1200 €general fund
    Aug, 2015anonymous3 €General fund
    Aug, 2015Sending Stickers9,90 €general fund
    Aug, 2015anonymous0.11211 BTCGeneral fund
    Aug, 2015anonymous0.0059006 BTCGeneral fund
    Sep, 2015Alex10 €General fund
    Sep, 2015susbarbatus35 €General fund
    Sep, 2015Alex10 €General fund
    Sep, 2015anonymous0.02387285 BTCGeneral fund
    Sep, 2015anonymous1 BTCGeneral fund
    Sep, 2015anonymous0.01 BTCGeneral fund
    Sep, 2015anonymous0.1 BTCGeneral fund
    Oct, 2015Alex10 €General fund
    Oct, 2015Alex10 €General fund
    Oct, 2015ComeIn3s10 €General fund
    Oct, 2015anonymous4,13 €General fund
    Oct, 2015anonymous0.01 BTCGeneral fund
    Oct, 2015anonymous0.01266157 BTCGeneral fund
    Oct, 201532C3 travel support9.2434 BTCGeneral fund
    Oct, 2015dg Android tablet0.4366 BTCGeneral fund
    Oct, 2015anonymous0.03037511 BTCGeneral fund
    Oct, 2015anonymous0.495 BTCGeneral fund
    Nov, 2015Alex10 €General fund
    Nov, 2015Alex10 €General fund
    Nov, 2015MC Red filling costs7,92 €general fund
    Nov, 201532C3 tickets270 €general fund
    Nov, 2015ComeIn3s10 €General fund
    Nov, 2015RWC 2016 support1.45 BTCGeneral fund
    + {{ _('2014 donations and costs:') }}
    @@ -151,7 +281,13 @@ with your name or nick (and optionally homepage) so we can list you here. - + + + + + + +
    datewhoincomeoutgoingaccount
    Dec, 2014donation Eol20 €General fund
    Dec, 2014donation ratsmack20 €General fund
    Dec, 2014donation50 €General fund
    May, 2014anonymous5 BTCSponge
    Dec, 2014anonymous5 BTCSponge
    Dec, 2014donation2 €General fund
    Dec, 2014donation JULLIAN David10 €General fund
    Dec, 2014I2P on 31C3 costs1257 €General fund
    Dec, 2014PayPal fees 2014121,9 €General fund
    Dec, 2014anonymous0.01579829 BTCGeneral fund
    Dec, 2014anonymous0.04728000 BTCGeneral fund
    Also we did got some donations of LTC. Current state is 703.981 LTC. For more From 4a5f417072fd3fbb774df709260c60e1e17d9374 Mon Sep 17 00:00:00 2001 From: echelon2 Date: Tue, 1 Dec 2015 17:03:17 +0000 Subject: [PATCH 045/114] small changes to hall of fame, recent subscriptions --- i2p2www/pages/site/about/hall-of-fame.html | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/i2p2www/pages/site/about/hall-of-fame.html b/i2p2www/pages/site/about/hall-of-fame.html index ebbfabdf..ce388bed 100644 --- a/i2p2www/pages/site/about/hall-of-fame.html +++ b/i2p2www/pages/site/about/hall-of-fame.html @@ -22,15 +22,15 @@ Current balance: as of {{ date }} {{ _('Bounty I2P for CCR Microtic Board') }}: 10 €

    -{{ _('Current monthly running costs:') }}
    +{{ _('Current running costs:') }}
    - - + + - +
    Welterde8 €/mo, since January, 2008 - i2p2.deEUServ root server660 €/year, since January, 2015
    eche|on40 €/mo since January, 2008 - i2p-projekt.de and domains71,40 €/year since January, 2013 - i2p-projekt.de and domains

    {% trans %}Big thanks go to the following people who have donated to I2P!{% endtrans %}

    @@ -41,7 +41,7 @@ with your name or nick (and optionally homepage) so we can list you here. {{ _('Current monthly subscriptions:') }}
    - +
    07/2014-07/2015JULLIAN David10 €{{ _('General fund') }}
    09/2015-08/2016Alex20 €{{ _('General fund') }}

    @@ -175,6 +175,9 @@ with your name or nick (and optionally homepage) so we can list you here. +We do accept Monero as donations, too. Currently no income. +
    +
    {{ _('2014 donations and costs:') }}
    From be71dd75d844841c60c00f4c6650a5826baf065b Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 1 Dec 2015 21:36:12 +0000 Subject: [PATCH 046/114] SAM 3.2: Clarifications SSU: Notes on RelayRequest --- i2p2www/pages/site/docs/api/samv3.html | 6 ++++-- i2p2www/pages/site/docs/spec/ssu.html | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 0f86f2c5..0df5debf 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -94,11 +94,13 @@ The following changes will be incorporated in the main part of this document soo
  • The server's control socket may optionally offer SSL/TLS support, as configured on the server and client. Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.
  • For STREAM FORWARD, client may add SSL=true to use an SSL socket -
  • New commands QUIT, STOP and EXIT will close the session and socket +
  • New commands QUIT, STOP and EXIT will close the session and socket. Implementation is optional, + for ease in testing via telnet.
  • Command parsing will properly handle UTF-8
  • Command parsing reliably handles whitespace inside quotes
  • A backslash '\' may escape quotes on the command line -
  • It is recommended but not required that the server map commands and option names to upper case. +
  • It is recommended but not required that the server map commands to upper case, for ease in testing via telnet. + Do not map keys to upper case, as this would corrupt I2CP options.
  • Empty option values such as PROTOCOL or PROTOCOL= may be allowed, implementation dependent.
  • Servers may implement timeouts for the HELLO or subsequent commands, implementation dependent. diff --git a/i2p2www/pages/site/docs/spec/ssu.html b/i2p2www/pages/site/docs/spec/ssu.html index fa99ca12..1bedd138 100644 --- a/i2p2www/pages/site/docs/spec/ssu.html +++ b/i2p2www/pages/site/docs/spec/ssu.html @@ -657,6 +657,7 @@ use the packet's source address and port. This message may be sent via IPv4 or IPv6. If IPv6, Alice must include her IPv4 address and port.
  • If Alice includes her address/port, Bob may perform additional validation before continuing. +Prior to release 0.9.24, Java I2P rejected any address or port that was different from the connection.
  • Challenge is unimplemented, challenge size is always zero
  • From 810d0d466165ac3084017726b77c0d2a199bf10c Mon Sep 17 00:00:00 2001 From: echelon2 Date: Wed, 2 Dec 2015 12:37:19 +0000 Subject: [PATCH 047/114] Update hall-of-fame --- i2p2www/pages/site/about/hall-of-fame.html | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/site/about/hall-of-fame.html b/i2p2www/pages/site/about/hall-of-fame.html index ce388bed..6b3eaa3f 100644 --- a/i2p2www/pages/site/about/hall-of-fame.html +++ b/i2p2www/pages/site/about/hall-of-fame.html @@ -6,7 +6,7 @@ Current balance: as of {{ date }} {%- endtrans %}
    {{ _('General fund') }}: -{% trans euroval='38828,28', btcval='516,95196524' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    +{% trans euroval='38838,28', btcval='516,95196524' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    {{ _('Datastorage bounty') }}: {% trans euroval='145.0', btcval='2' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    {{ _('I2PHex bounty') }}: @@ -170,9 +170,12 @@ with your name or nick (and optionally homepage) so we can list you here.
    • + + +
    datewhoincomeoutgoingaccount
    Nov, 2015MC Red filling costs7,92 €general fund
    Nov, 201532C3 tickets270 €general fund
    Nov, 2015ComeIn3s10 €General fund
    Nov, 201532C3 tickets90 €general fund
    Nov, 2015RWC 2016 support1.45 BTCGeneral fund
    Dec, 2015Alex10 €General fund
    We do accept Monero as donations, too. Currently no income. From ff9fea83638d30b7083a25cf96828364f0f1ace5 Mon Sep 17 00:00:00 2001 From: echelon2 Date: Wed, 2 Dec 2015 14:46:37 +0000 Subject: [PATCH 048/114] small changes, clarification on MasterCard Red --- i2p2www/pages/site/about/hall-of-fame.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/i2p2www/pages/site/about/hall-of-fame.html b/i2p2www/pages/site/about/hall-of-fame.html index 6b3eaa3f..2795df52 100644 --- a/i2p2www/pages/site/about/hall-of-fame.html +++ b/i2p2www/pages/site/about/hall-of-fame.html @@ -108,15 +108,15 @@ with your name or nick (and optionally homepage) so we can list you here. Jun, 2015Alex10 €General fund Jun, 2015anonymous3 €General fund - Jun, 2015travel support kytv6 BTCGeneral fund - Jun, 2015travel support cacapo1 BTCGeneral fund + Jun, 2015travel support I2Pcon6 BTCGeneral fund + Jun, 2015travel support I2Pcon1 BTCGeneral fund Jun, 2015anonymous0.0488 BTCGeneral fund Jul, 2015JULLIAN David10 €General fund Jul, 2015anonymous3 €General fund Jul, 2015anonymous0.00485993 BTCGeneral fund - Jul, 2015travel support psi1.5 BTCGeneral fund + Jul, 2015travel support I2Pcon1.5 BTCGeneral fund Jul, 2015anonymous0.00581971 BTCGeneral fund Jul, 2015anonymous0.04 BTCGeneral fund Jul, 2015anonymous0.00839704 BTCGeneral fund @@ -133,10 +133,10 @@ with your name or nick (and optionally homepage) so we can list you here. Aug, 2015stickers10 €General fund Aug, 2015anonymous20 €General fund Aug, 2015stickers19 €General fund - Aug, 2015MC Red costs33 €general fund + Aug, 2015MasterCard Red buying costs33 €general fund Aug, 2015MC Red filling cost11,40 €general fund - Aug, 2015Toronto I2Pcon costs400 €general fund - Aug, 2015Toronto MC Red costs553,62 €general fund + Aug, 2015Toronto I2Pcon spents: sweets,HackLab rent,misc400 €general fund + Aug, 2015Toronto spents from MC Red: dinner,drinks553,62 €general fund Aug, 2015Toronto travel support1200 €general fund Aug, 2015anonymous3 €General fund Aug, 2015Sending Stickers9,90 €general fund From 1f7c5ba24806b71b89886414783fbd257c96d8fb Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 4 Dec 2015 02:26:59 +0000 Subject: [PATCH 049/114] Better bottom shadow --- i2p2www/static/styles/duck/default.css | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css index cf9ea986..99da77fb 100644 --- a/i2p2www/static/styles/duck/default.css +++ b/i2p2www/static/styles/duck/default.css @@ -174,6 +174,16 @@ div#content .inner:before { width: 100%; } +div#content .inner:after { + bottom: 0; + box-shadow: 0px -6px 12px -12px inset; + content: " "; + height: 12px; + left: 0; + position: absolute; + width: 100%; +} + div#content .inner .fluid { background-color: #fefff1; } @@ -456,7 +466,6 @@ pre.literal-block { width: auto; border-top: 3px solid #883333; background: #552222; - box-shadow: 0px -4px 8px rgba(0,0,0,.3); font-size: 0.75rem; padding: 1em 10%; background: -moz-linear-gradient(#883333, #772222); From c7a1307c1ed14b800ae297b85fa99e809b927129 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 4 Dec 2015 05:22:08 +0000 Subject: [PATCH 050/114] RTL fixes --- i2p2www/static/styles/duck/desktop.rtl.css | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/i2p2www/static/styles/duck/desktop.rtl.css b/i2p2www/static/styles/duck/desktop.rtl.css index 5f78aa73..03a83bc4 100644 --- a/i2p2www/static/styles/duck/desktop.rtl.css +++ b/i2p2www/static/styles/duck/desktop.rtl.css @@ -60,6 +60,7 @@ div#content .main { /** Content **/ div#content .inner .fluid { + background-position: right; border-left: none; border-right: 2px solid #abcc71; margin-left: 0; @@ -76,6 +77,8 @@ div#content .inner .sidebar { div#content .content-inner { margin-left: 0; margin-right: 252px; + padding-left: 4em; + padding-right: 2em; } @@ -93,6 +96,13 @@ div#content .content-inner { float: right } -.details .hash { - float: left +.file .default { + clear: right; + float: right; +} + +.file .mirrors, +.file .sig { + clear: left; + float: left; } From 735fe06b103215917716c850cf8c4fa22e539081 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 6 Dec 2015 18:18:05 +0000 Subject: [PATCH 051/114] new reseed server docs, moved from zzz.i2p --- i2p2www/pages/downloads/list.html | 2 +- i2p2www/pages/site/docs/index.html | 2 + .../site/get-involved/guides/reseed.html | 1014 +++++++++++++++++ i2p2www/pages/site/get-involved/index.html | 5 + 4 files changed, 1022 insertions(+), 1 deletion(-) create mode 100644 i2p2www/pages/site/get-involved/guides/reseed.html diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index 8ccd4824..811aca08 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -41,7 +41,7 @@ or type java -version at your command prompt.

    {{ _('Release Notes') }}

    • -{{ _('Release Notes') }} +{{ _('Release Notes') }}
    • {{ _('Change Log') }}
    • diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index 739b45e0..8eae8128 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -221,6 +221,8 @@ Traditionally used only by Java applications and higher-level APIs.
    • {{ _('Embedding the router in your application') }}
    • +{{ _('How to Set up a Reseed Server') }} +
    • {{ _('Ports used by I2P') }}
    • {{ _('Automatic updates to development builds inside I2P') }} diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html new file mode 100644 index 00000000..d42eb4d0 --- /dev/null +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -0,0 +1,1014 @@ +{% extends "global/layout.html" %} +{% block title %}{{ _('How to Set up a Reseed Server') }}{% endblock %} +{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} +{% block content %} + +

      {% trans %}Overview{% endtrans %}

      + +

      {% trans -%} +Thank you for volunteering to run an I2P reseed server. +"Reseeding" is our term for bootstrapping new routers into the network. +New routers fetch a bundle of peer references, or "router infos", from one or more of a hardcoded list of HTTPS URLs. +{%- endtrans %}

      + +

      {% trans %}Requirements{% endtrans %}

      + +

      {% trans -%} +At its simplest, a reseed server consists of a Java I2P router, an HTTPS web server, +and some scripts that periodically gather router infos from the router, +bundle and sign them into a custom file format, and deliver these files over HTTPS. +In practice, it's a bit more complex, and a reseed operator must be fairly competent and attentive. +A reseed server is not appropriate for a residential internat connection. The complexities include: +{%- endtrans %}

      + +
        +
      • {% trans -%} +You must have a secure SSL setup with either a self-signed certificate or a cert that chains up to a standard CA +{%- endtrans %}
        • +
      • {% trans -%} +The SSL configuration must conform to current best practices on allowed ciphers and protocols, and the CN/SAN host name must match the URL +{%- endtrans %}
        • +
      • {% trans -%} +The scripts are designed to deliver different router info bundles to different requestors for nextwork diversity +{%- endtrans %}
        • +
      • {% trans -%} +The scripts are designed to deliver the same bundle to the same repeated requestor to prevent scraping +{%- endtrans %}
        • +
      • {% trans -%} +The reseed servers are under periodic attacks and DDoS attempts, and from buggy botnet i2pd routers. +This necessitates that you run fail2ban or an equivalent solution. +{%- endtrans %}
        • +
      + +

      {% trans %}Information Required{% endtrans %}

      + +

      {% trans -%} +When your setup is complete and ready for testing, we will need the HTTPS URL, +the SSL public key certificate, and the "su3" bundle public key. +After testing is complete, these will be added to the hardcoded entries in the Java and C++ routers in the next release, +and you will start seeing traffic. +We also will need your email address so we may continue to contact you about reseed administration issues. +The email will not be made public but will be known to the other reseed operators. +You should expect that your nick or name and its association with that URL or IP will become public. +{%- endtrans %}

      + +

      {% trans %}Privacy Policy{% endtrans %}

      + +

      {% trans -%} +A reseed operator is a trusted role in the network. +While we do not yet have a formal privacy policy, you must ensure the privacy of our users +by not publicizing logs or IPs found in those logs, except as necessary to discuss administration issues with the I2P reseed team. +{%- endtrans %}

      + +

      {% trans %}Getting Started{% endtrans %}

      + +

      {% trans -%} +Our reseed coordinator is "backup" and he may be contacted at backup@mail.i2p or backup at i2pmail.org. +Unfortunately, he is not generally on IRC. The reseed setup is somewhat specialized, and you should direct most questions to him. +{%- endtrans %}

      + +

      {% trans -%} +For actual implementation, details are at the links below. In summary, there are two solutions we have to offer: +{%- endtrans %}

      + +
        +
      1. {% trans -%} +A Go implementation that includes the web server and all the scripts. This is the recommended solution. +{%- endtrans %}
        2. + +
      2. {% trans -%} +An older PHP implementation plus some shell scripts. The PHP goes into a web server that you must set up separately. +{%- endtrans %}
        3. +
      + +

      {% trans -%} +For further information, read the information at the following links, and then contact backup. +Thank you! +{%- endtrans %}

      + + + +

      {% trans %}Detailed Instructions{% endtrans %}

      + +
      +
+
+-------------------------------------------------------------------------------
+2015-05-09 backup
+ * new chapter: reverse-proxy setup (idea by kytv and review from matt)
+ * ==> howto_public_reseed_server_v6.txt
+
+2015-03-23 backup (with much help from matt)
+ * Script - su3.php - added support for running INSIDE i2p-net (DESTB32)
+ * Script - su3.php - added proper html header for downloading in any browser
+ * Script - cronjob_i2p.sh - minor code cleanups
+ * Script - cronjob_i2p.sh - added FINAL CHECK number su3-files
+ * new chapter: Optional - setup a manual reseed method, secured by captcha
+ * new chapter: matt's go solution - Overview
+ * new chapter: matt's go solution - Building from source
+ * new chapter: matt's go solution - Run the reseed server
+ * new chapter: matt's go solution - Draft for startup script
+ * new chapter: matt's go solution - Convert existing java keystore to crt- and pem-file
+ * ==> howto_public_reseed_server_v5.txt
+
+2015-01-22 backup	
+ * Script - cronjob_i2p.sh - minor code cleanups with shell script validator/parser
+ * Script - su3.php - minor code cleanup (404 redirect), thanks to "drgr33n"
+ * we want only HTTPS accessible reseed server
+ * Testings - added some wget options for the ssl-certificate, thanks to "drgr33n"
+ * ==> howto_public_reseed_server_v4.txt
+
+2014-12-26 backup
+ * Script - cronjob_i2p.sh - config variable "target" without ending "/"
+ * meeh completely removed in contacts
+ * new chapter: reseed server domain/url/port exchange
+ * chapter "requirements" expanded - traffic volume, attacks, webserver-port!=443
+ * chapter "Create self-signed ssl-certificate" - use rsa, not ecdsa
+ * ==> howto_public_reseed_server_v3.txt
+
+2014-12-13 backup
+ * new chapter: Create self-signed ssl-certificate
+ * new chapter: Seamless ssl-cert exchange
+ * meeh's solution removed
+ * cronjob_i2p.sh: example target path changed to "/var/www/su3/" for clarification
+ * ==> howto_public_reseed_server_v2.txt
+
+2014-10-17 backup
+ * initial release v1
+
+
+
+
+-------------------------------------------------------------------------------
+How-to Public reseed servers - su3
+
+- Some parts of this how-to are copied from http://zzz.i2p and are modified.
+- Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to.
+- Questions can be placed on http://zzz.i2p/forums/18 - in the Reseeding sub-forum.
+
+
+
+
+-------------------------------------------------------------------------------
+0. Table of contents
+
+1. Intro
+2. Requirements
+3. Short overview
+4. su3-file guidelines for reseeding
+5. How to prepare your key pair for su3-files
+6. su3 server-side implementation
+7. unix shell script for cronjob
+8. Setup cronjob
+9. php script for webserver
+10. url rewrite rule for webserver
+11. Create self-signed ssl-certificate
+12. Seamless ssl-certificate exchange
+13. reseed server domain/url/port exchange
+14. Testings
+15. Contact reseed maintainer
+16. Script - cronjob_i2p.sh
+17. Script - su3.php
+18. Optional - setup a manual reseed method
+19. matt's go solution - Overview
+20. matt's go solution - Building from source
+21. matt's go solution - Run the reseed server
+22. matt's go solution - Draft for startup script
+23. matt's go solution - reverse-proxy setup
+24. matt's go solution - Convert existing java keystore to crt- and pem-file
+
+
+
+
+-------------------------------------------------------------------------------
+1. Intro
+
+Public reseed servers are necessary to bootstrap into the i2p net.
+New installed i2p routers needs one-time a handful RouterInfo's (RI) as jump start.
+
+RI contains IP and Port from other i2p-routers and are stored in dat-files in the netDB folder.
+
+A random bunch of dat-files from the netDB are zipped, then signed to a su3-file
+and finally offered to i2p-routers seeking reseed service.
+
+To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory.
+
+It is essential not to publish all RI from netDB, or all RI to one client.
+So a cronjob will be setup providing only a part of all available RI.
+
+A php script ensures that requests to the public reseed server provides only
+one su3-file within 24h for one client IP.
+
+
+
+
+-------------------------------------------------------------------------------
+2. Requirements
+
+Requirements for running a public reseed server:
+- well integrated running i2p router @ 24/7 {% endblock %}
+- server with static IPv4 (2 cpu/ 2GB ram is already fine)
+- unix to run the shell script, cronjobs or matts solution
+- own domain, a third level domain is fine too and may provide you with more anonymity.
+- a self signed ssl-certificate is ok
+- web-space (HTTPS only) with php5+rewrite-rule
+- HTTPS only, with TLS 1.2, only with good ciphers
+- enough bandwidth and traffic volume (due to a annoying botnet expect up to 1TB per month)
+- fail2ban to protect you from the botnet
+
+This How-to is tested with Ubuntu/Debian
+The web-space has to be public reachable from all over the world, an eepsite inside i2p can be setup in addition.
+Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server.
+The webserver doesn't need to listen at default SSL/TSL port 443 - any other port can be used for obfuscation.
+
+
+
+
+-------------------------------------------------------------------------------
+3. Short overview
+
+- permanent: run your i2p router
+- once: generate a private and public key pair for signing the reseed files
+- once: setup the php script on the web-space
+- once: setup a rewrite rule at webserver (*.su3 --> su3.php)
+- regularly: run the unix shell script to generate up-to-date su3-files
+- regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web-space
+
+
+
+
+-------------------------------------------------------------------------------
+4. su3-file guidelines for reseeding
+
+(From http://zzz.i2p/topics/1648)
+- The su3-file must be named "i2pseeds.su3"
+- The file must be in the same directory as the routerinfos on the web server
+- Router will first try to fetch (index url)/i2pseeds.su3;
+  if that fails it will fetch (index url) and then fetch the individual RI files, old-style
+- Once a reseed from a host succeeds, it won't try any other URLs from that host
+  (either http or https, ignoring ports... ports are now implemented)
+- RI files in the zip file (in the su3-file) must be at the "top level",
+  i.e. no directories in the zip file
+- su3 content type must be RESEED (-c 3 or -c RESEED)
+- su3 signature type should be RSA 4096 (-t 6 or -t RSA_SHA512_4096).
+  If you're very low on CPU power you could use a shorter key, but you only need to do the signing process once a day or so.
+  Any sig type will work, but RSA 4096 is the best in this case.
+- Of course we must have your su3 signing public key checked in
+  under the same name as you are using in the signing process,
+  e.g. for you@mail.i2p the file name must be you_at_mail.i2p.crt, in the certificates/reseed/ directory
+
+
+
+
+-------------------------------------------------------------------------------
+5. How to prepare your key pair for su3-files
+
+( from http://zzz.i2p/topics/1643)
+Details are posted here from zzz: http://zzz.i2p/topics/1473
+Who? All owner of a public reseed server.
+Why? su3 reseed files will be signed with your private key.
+This ensures a secure bootstrap for i2p routers.
+Corresponding public keys will be included in i2p router package.
+Example to create your key pair:
+	su - i2puser
+	I2P=/home/i2puser/i2p
+	cd $I2P
+	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File keygen -t RSA_SHA512_4096 backup_at_mail.i2p.crt keystore.ks backup@mail.i2p
+Short usage help:
+	SU3File keygen [-t type|code] publicKeyFile keystore.ks you@mail.i2p
+Get more help:
+	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File
+Provide a strong password for your private key.
+In this example two new files will be created in the working folder:
+- backup_at_mail.i2p.crt	will contain the public key
+- keystore.ks			is the Java keystore file and contains your private key
+Backup and store public key, private key and your password!
+Remember also the used key size/type when not using default RSA_SHA512_4096.
+Send the public .crt key file to us, to include it into i2p/certificates/reseed/
+If you have mtn privs, you may check the (you)_at_mail.i2p.crt file directly into installer/resources/certificates/reseed .
+The file name must be (email address used for signing).crt, with "@" replaced with "_at_".
+There is no requirement that it be xxx@mail.i2p, any email is fine, or for that matter any identifier.
+
+
+
+
+-------------------------------------------------------------------------------
+6. su3 server-side implementation
+
+(from http://zzz.i2p/topics/1647)
+This describes a mechanism for creating and distributing the RI in new su3 format.
+It's independent from legacy way of doing (fetching dat-files) and can be used in parallel.
+This idea don't need mysql, only some Unix shell tools and a simple web-space with php works fine.
+
+A requesting client gets ~75 RI packed into one zip, signed and converted to a su3-file.
+Don't provide unlimited RI to one clients.
+But don't try to keep track of million client IP's in a database, e.g think of ipv6.
+Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo.
+n is the unlimited IPv4+IPv6 address space, and m are e.g. 100 pre-calculated su3-files.
+A client with one IP gets always the same su3-file, until the su3-file is updated or the client has a new IP.
+A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in i2p net grow.
+
+Once or twice a week (or daily): pre-calculate ~100 new su3-files, each includes ~75 RI.
+The RI are fetched from a well running i2p router's netdb directory.
+Transfer the pre-calculate su3-files to your web-space, e.g. by sftp or copy them locally to /var/www/su3/.
+In the web-space a php script will match one client IP to one of the 100 su3-files by hash+modulo.
+This has the advantage to split su3-generation and publishing in web-space .
+
+Requirements for su3-file generation:
+- 24/7 running i2p-router with up to date netdb
+- ziptool, e.g. "zip" (Debian/Ubuntu: sudo apt-get install zip)
+- Unix shell: find, awk, cat, ...
+- your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password
+Requirements for web-space :
+- php5
+- rewrite rule (*.su3 --> php)
+
+The following solution for a public reseed server consists of three parts:
+- unix shell script for cronjob
+- php script
+- url rewrite rule
+They are described on the following chapters in more detail.
+
+
+
+
+-------------------------------------------------------------------------------
+7. unix shell script for cronjob
+
+This script pre-calculates n su3-files.
+Requirements: unix shell, java, i2p, zip-tool, your private reseed signing key
+Main Steps:
+# CONFIG
+# CHECK REQUIREMENT
+# CREATE index files from netdB: use only 66% and max. 10h old
+# CREATE zip files
+# CREATE su3 files
+# FINALIZE
+Please check and edit #CONFIG sections, please review code before use.
+The resulting su3-files are placed in the "target" folder which can be changed in config section with "target".
+Configure file permissions and file owner e.g. 'www-data' - see deactivated example lines.
+The cronjob script runs ca. 10 seconds for generating 100 pre-calculated su3 files on a modern cpu.
+The number of dat-files per su3 package is random. If you configure 75, it results in ca. 50...100 dat-files per su3-file.
+The number of generated su3-files is random too, it depends on your netdb size and adapts automatically:
+- 1000 netdb entries: used for publishing:  ~666, results in  ~66 su3-files, each with ~75 dat-files
+- 3000 netdb entries: used for publishing: ~1999, results in ~199 su3-files, each with ~75 dat-files
+Only 66% of all RI from your netdb are used, netdb may be not older than 10h.
+It is possible to separate cronjob script from php script:
+Run the cronjob script on your i2p machine and then transfer the final su3-files via (s)ftp/ssh
+to your webserver from time to time. su3 file-size in this setup is between 50 and 100 KB per file.
+
+
+
+
+-------------------------------------------------------------------------------
+8. Setup cronjob
+
+Please add a cronjob, e.g. to run it every few days.
+Add the shell script in crontab, e.g.:
+	crontab -e
+	23 59 * * * /usr/local/bin/cronjob_i2p.sh
+The hard limit for the su3-file age is 30 days.
+Recommendation is to update the su3-files once every 1..10 days.
+
+
+
+
+-------------------------------------------------------------------------------
+9. php script for webserver
+
+The su3.php script maps always one client IP to one pre-calculated su3-file.
+Requirements: a webserver with php5
+Main Steps:
+# CONFIG
+# HEALTH CHECK
+# COUNT su3 files
+# MAPPING Client IP to one SU3
+# PROVIDE SU3
+Please check and edit #CONFIG sections, please review code before use.
+
+The date() function in the salt ensures a rotate once a day, even if su3-files are not updated daily.
+To avoid scraping from attackers with big IPv4 subnet resources
+(or even IPv6) some lower bytes of the client IP address are discarded:
+- IPv4:  4 byte  --> 1 lowest byte
+- IPv6: 16 bytes --> 8 lowest bytes
+Clients in the same "subnet" gets the same su3-file
+
+A clients gets only different su3-file package in following circumstances:
+- when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address)
+- at 00:00 every date (date function in php)
+- when the unix cronjob updates the su3 files
+
+
+
+
+
+-------------------------------------------------------------------------------
+10. url rewrite rule for webserver
+
+It is mandatory that clients does not have direct access to the su3-files at the webserver.
+Please activate a rewrite rule for su3-files in your webserver pointing to the su3.php file:
+	*.su3 --> su3.php?file=$1
+
+Apache in ".htaccess":
+	Options +FollowSymlinks
+	RewriteEngine On
+	RewriteRule ^(.*\.su3)$ /su3.php?file=$1 [L]
+
+lighttpd in "/etc/lighttpd/lighttpd.conf":
+	server.modules += ( "mod_rewrite" )
+	url.rewrite-once = ( "^(.*\.su3)$" => "/su3.php?file=$1" )
+
+We want only HTTPS accessible reseed server.
+Sorted by best solution:
+ * please deactivate plain HTTP, or
+ * use a redirect rule in your webserver, or
+ * implement the redirect to HTTPS in the php-code
+
+
+
+
+-------------------------------------------------------------------------------
+11. Create self-signed ssl-certificate
+
+How-to generate a new self-signed ssl-certificate for HTTPS/TLS with openssl.
+Example command line in Debian/Ubuntu for your.server.com:
+
+$ openssl req -x509 -nodes -days 1500 -newkey rsa:4096 -sha256 -keyout your.server.com.pem -out your.server.com.pem
+...
+Country Name (2 letter code) [AU]:UK
+State or Province Name (full name) [Some-State]:your.server.com
+Locality Name (eg, city) []:your.server.com
+Organization Name (eg, company) [Internet Widgits Pty Ltd]:your.server.com
+Organizational Unit Name (eg, section) []:your.server.com
+Common Name (e.g. server FQDN or YOUR name) []:your.server.com
+Email Address []:your.server.com
+
+--> The result is stored in "your.server.com.pem" file
+
+Remarks:
+- Please fill out all fields, don't use blanks
+- rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu
+- use rsa, not ecdsa (ecdsa will break currently RetHat users)
+- days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years))
+- sha256 - important, without this option openssl currently uses weak sha1 by default
+- Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup.
+
+Next step:
+- Open the created pem-file with a simple text editor.
+- You see the section with the private key and the section with the public key.
+- Copy the public section (starting with -----BEGIN CERTIFICATE-----) to another new file
+- and save the new file as your.server.com.crt file
+--> Send this to us - the .crt file with the public key section will we included in every i2p router.
+--> The .pem file with your private key is only for you and your webserver.
+
+
+
+
+-------------------------------------------------------------------------------
+12. Seamless ssl-certificate exchange
+
+The update/exchange of an already existing self-signed certificates has to be correct timed
+on server *and* client side. Considering thousands of clients (many with older i2p version) the exchange
+will not be seamless possible and will have very bad impact on many clients: reseed won't work for them.
+
+To avoid this issue and make the exchange as smooth as possible follow these simple steps:
+
+1. generate a new ssl-certificate NOW, but do NOT implement it on server
+2. send the new ssl-certificate to us to perform a roll-out towards clients NOW
+3. WAIT some month, e.g. 3-4 i2p-releases
+4. new ssl-certificate is now hopefully present on many clients (in parallel to the current/old one)
+5. THEN exchange the ssl-certificate on server
+
+This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g.
+server.com.crt and server.com2.crt
+
+
+
+
+-------------------------------------------------------------------------------
+13. reseed server domain/url/port exchange
+
+
+You are already operating a reseed server but want to change your domain/url/port?
+To make the exchange as smooth as possible for many clients please follow these steps if possible:
+
+a) Setup an additional reseed instance at the new domain/url/port
+b) we include the new url into i2p source NOW and delete the old url NOW
+c) both of your reseed instances have to run some time in parallel
+d) WAIT some month, e.g. 3-4 i2p-releases
+e) new url is now hopefully present on many clients
+f) THEN shutdown the old reseed instance
+
+
+
+
+-------------------------------------------------------------------------------
+14. Testings
+
+Some simple pre-test: test the website and fetch
+	wget --user-agent="Wget/1.11.4" -O /tmp/test.su3 --no-check-certificate https://your-server.com:PORT/i2pseeds.su3
+Replace "PORT" with default 443 or your chosen server setting.
+Inspect the fetched file:
+	zipinfo -z /tmp/test.su3
+
+Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt"
+which contains the path to your local public ssl-certificate to check also your ssl-certificate chain.
+
+Everything ok:
+- ssl-certificate chain valid?
+- The su3-files can be downloaded?
+- contains >50 dat-files?
+- and is always the same for one client-IP?
+- other client-IP's gets another file?
+- Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ?
+
+Do a real reseed test on *another* i2p router machine:
+- include manually new ssl-certificate into i2p installation:	~/i2p/certificates/ssl/
+- include manually new public reseed key into i2p installation:	~/i2p/certificates/reseed/
+- http://localhost:7657/configreseed --> remove all reseed hosts
+- add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3"
+- Save and Shutdown router.
+- clear netdb: empty folder ./i2p/netDb.
+- Restart i2p and watch the i2p router log:
+2014/10/13 23:01:02 | Reseed start
+2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
+2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
+2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
+2014/10/13 23:01:06 | Reseed complete, xx received
+
+
+
+
+-------------------------------------------------------------------------------
+15. Contact reseed maintainer
+
+Contact us per email backup@mail.i2p (fallback is killyourtv@mail.i2p or the reseed section at zzz's forum)
+Provide us details about the new
+ - reseed website url,
+ - public part of ssl-certificate
+ - public su3-key
+ - your contact email
+Feel free to contact backup@mail.i2p in case of questions or problems or post your question at zzz's forum in the reseed section.
+
+
+
+
+-------------------------------------------------------------------------------
+16. Script - cronjob_i2p.sh
+
+###############################################################################
+#!/bin/sh
+version="v5"
+
+
+# CONFIG
+I2P="${HOME}/i2p"			# i2p installation directory
+source="${HOME}/.i2p/netDb"		# valid netdb
+target="${HOME}/i2pseeds.su3"		# location for the final su3-files
+
+key_keystore="${I2P}/keystore.ks"	# your private su3 reseed key
+key_password="secret"			# your password for private key of keystore.ks
+key_email=yourmail@mail.i2p		# your email id for reseeding
+key_type=RSA_SHA512_4096		# your key size/type for reseeding (DO NOT EDIT, unless you know why)
+
+tool_zip="/usr/bin/zip"			# install a "zip" tool: sudo apt-get install zip
+tool_i2p="$I2P/lib/i2p.jar"		# should be already there
+
+
+# CONFIG (DO NOT EDIT)
+ri_seed=75				# average number ri per su3-file (DO NOT EDIT)
+stamp=$(date +%s)			# unique id (DO NOT EDIT)
+target_tmp="/tmp/i2pseeds.${stamp}.tmp"	# temp folder with unique id (DO NOT EDIT)
+
+
+# CLEAN /tmp/i2pseeds.*
+find /tmp -type d -iname 'i2pseeds.*.tmp' -exec rm -rf {} \;
+mkdir --parents "${target_tmp}"
+
+
+# CHECK REQUIREMENT
+[ ! -d "${I2P}" ]          && echo "ERROR1: path not found: ${I2P}"          && exit 1
+[ ! -d "${source}" ]       && echo "ERROR2: path not found: ${source}"       && exit 1
+[ ! -d "${target_tmp}" ]   && echo "ERROR3: path not found: ${target_tmp}"   && exit 1
+[ ! -x "${tool_zip}" ]     && echo "ERROR4: command not found: ${tool_zip}"  && exit 1
+[ ! -f "${tool_i2p}" ]     && echo "ERROR5: file not found: ${tool_i2p}"     && exit 1
+[ ! -f "${key_keystore}" ] && echo "ERROR6: file not found: ${key_keystore}" && exit 1
+
+
+# CREATE index-files from netdB: use only 66% and max. 10h old
+find "${source}" -type f -mmin -600 -name 'routerInfo-*.dat' | awk -v ri_seed="${ri_seed}" -v target_tmp="${target_tmp}" '
+	BEGIN { ri_all=0; }
+	{	data[ri_all++]=$0; }
+	END {	srand();
+		ri_use=ri_all*0.6666;
+		ri_su3=int(ri_use/10);
+		stepy=ri_use/ri_all;
+		stepx=ri_seed/ri_use;
+		for (y=0;y> file
+			}
+		}
+	}'
+
+
+# CREATE zip-files from index-files
+find "${target_tmp}" -type f -name '*.index' | sort | while read i; do
+	"${tool_zip}" --update --quiet --junk-paths "${target_tmp}/$(basename "$i" .index)" -@ < "$i"
+done
+
+
+# CREATE su3-files from zip-files
+echo "${key_password}" | java -cp "${tool_i2p}" net.i2p.crypto.SU3File bulksign -c RESEED -t "${key_type}" "${target_tmp}" "${key_keystore}" "${stamp}" "${key_email}"
+
+
+# REMOVE index-files and zip-files
+find "${target_tmp}" -type f -name '*.index' -exec rm -f "{}" \;
+find "${target_tmp}" -type f -name '*.zip'   -exec rm -f "{}" \;
+
+
+# FINAL CHECK number su3-files
+c_su3=$(find "${target_tmp}" -type f -mmin -600 -name '*.su3' | wc -l)
+[ "${c_su3}" -lt 25 ] && echo "ERROR7: less than 25 su3 files found: ${c_su3}" && rm -Rf "${target_tmp}" && exit 1
+echo "Created: $target_tmp ${c_su3} x${ri_seed}"
+
+
+# MOVE su3-files to target
+chmod 755 "${target_tmp}" -R
+rm -fr "${target}.old"
+mv -f  "${target}"     "${target}.old"
+mv -f  "${target_tmp}" "${target}"
+rm -fr "${target_tmp}"
+
+
+# EXIT
+echo      "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
+logger -t "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
+exit 0
+###############################################################################
+
+
+
+
+-------------------------------------------------------------------------------
+17. Script - su3.php
+
+###############################################################################
+8) { $shrink=8; };
+$remote_id = abs(crc32(md5(substr($remote_id,0,$shrink).$salt))) % $count_su3;
+$file_id = $path_su3."/".$remote_id.".su3";
+
+
+# HEALTH CHECK 3
+if (!file_exists($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+
+
+# PROVIDE su3-file
+header('Content-Description: File Transfer');
+header("Content-Type: application/zip");
+header('Content-Transfer-Encoding: binary');
+header('Content-Length: '.filesize($file_id));
+header('Content-Disposition: attachment; filename='.$file_su3);
+ob_clean(); flush();
+if (!readfile($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+exit;
+?>
+###############################################################################
+
+
+
+
+-------------------------------------------------------------------------------
+18. Optional - setup a manual reseed method
+
+For some users the automated reseeding may not work.
+This is an alternate way for users to get a valid reseed file with a normal web-browser,
+e.g. from another machine or maybe a friend. It is secured by a captcha to prevent abuse.
+
+With this optional code users can visit https://your.reseedserver.com/reseed.php
+with any web-browser to download a su3-file after they solved the captcha.
+
+Since 0.9.18-9 I2P has support to use reseed files from other sources:
+http://localhost:7657/configreseed
+
+Visit https://geti2p.net/en/faq#manual_reseed to read how it works for users and see some example url's.
+[NOT DONE YET: read here: http://zzz.i2p/topics/1828-running-prototype-manually-reseed-captcha
+or test here anonymously: http://reseed.i2p/open.php]
+
+The changes for an exiting reseed server with the previous setup are simple:
+- use the latest su3.php from above (minimal version 5, only minor changes, no change of logic).
+- add the new reseed.php to your /var/www folder, next to to su3.php
+- install php5-gd (restart of php processes may be necessary)
+- get Securimage php-code from https://www.phpcaptcha.org/
+
+Quote from https://www.phpcaptcha.org  (2015-03):
+"Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect
+forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots.
+It can run on most any webserver as long as you have PHP installed, and GD support within PHP.
+Securimage does everything from generating the CAPTCHA images to validating the typed code."
+
+Short overview about installing Securimage:
+ 1. download at https://www.phpcaptcha.org/download/
+ 2. extract to /var/www/securimage
+ 3. download and extract the "Test Script" (securimage_test.php) from the same url
+ 4. test your server and visit https://.../securimage_test.php with your browser
+The "Test Script" verifies your ability to run and display the captcha code, and can be deleted after the test.
+
+The reseed.php contains only the captcha generation and verification of the users input. It is based on the
+Quickstart Guide from Securimage. When the user solved the captcha, reseed.php sets two http variables and
+then includes the external su3.php to start the su3-file download.
+
+The name "reseed.php" is not fixed, you can name it unremarkable/unobtrusive as you like,
+enter.php start.php go.php...
+but you have to stick with it, when it is published :-)
+
+reseed.php:
+################################################################################################
+
+
+check($_POST['captcha_code']) == false) {?>
+	
      
+	CAPTCHA Image
+	
      Enter Code: 
+	
+	
      
+
+
+################################################################################################
+
+
+
+
+-------------------------------------------------------------------------------
+19. matt's go solution - Overview
+
+The previous steps for reseeding involves many steps, scripts and programs.
+Most of them are easy and plain straight forward, but overall you can call it a little confusing.
+
+Here comes now an all-in-one solution from matt (Big Thanks!) for providing
+a reseed server which merges the following functions into one binary:
+
+- create su3-files
+- create su3 signer certificate+key
+- create ssl-certificate+key
+- replaces the http-server and the php code (or run next to them in parallel)
+
+Almost all previous used scripts and described steps are not needed with this solution,
+but to understand the overall reseed process it is recommended to read them too :-)
+
+ - If you already have an ssl-certificate and su3-signer-key you can reuse them, see one of the following chapter.
+ - For testing and new reseeders the required certs and keys are created automatically at first start.
+ - Also take a look at the content and the naming scheme of these pem and crt files.
+
+Of course you need an up-to-date netDB folder with routerinfos from a running i2p router.
+I2P does not have to be running on the same machine as this reseed binary.
+In this case you can setup a cronjob to transfer the netDB from the I2P machine to the reseed machine.
+
+Matt's go solution can be used in parallel next to an already running http-server.
+For this leave the http-server running at normal port 80 and 443,
+and configure matt's go solution too use another port, e.g. port 8443.
+
+More: at github, README.md, https://github.com/MDrollette/i2p-tools
+
+
+-------------------------------------------------------------------------------
+20. matt's go solution - Building from source
+
+Requirements:
+ - go1.4.2 (older versions may not work)
+
+Install go from https://golang.org/doc/install, example for 64 bit Ubuntu/Debian:
+ - wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz
+ - sudo tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz
+ - mkdir $HOME/go
+ - edit /etc/profile and add:
+	export GOPATH=$HOME/go
+	export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
+
+Verify go:
+$ go version
+which should state something like: "go version go1.4.2"
+
+Install matt's go solution from https://github.com/MDrollette/i2p-tools into $HOME/go:
+$ go get github.com/MDrollette/i2p-tools
+
+This will install a binary to $GOPATH/bin/i2p-tools
+
+Run the go solution, the usage/help should be displayed, nothing more:
+$ i2p-tools
+
+
+
+
+-------------------------------------------------------------------------------
+21. matt's go solution - Run the reseed server
+
+$ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb
+
+- replace myserver.com with your real domain
+- replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose
+- new TLS certificate+key will be created (if they do not exist)
+- new signing certificate+key will be created (if they do not exist)
+- netdb=... should point to the netdb folder of your running i2p with the routerinfos
+- to use another port append "--port=443" to the command, default is port 8443
+
+Output:
+2015/03/15 12:28:25 Rebuilding su3 cache...
+2015/03/15 12:28:25 Building 200 su3 files each containing 75 out of 3180 routerInfos.
+2015/03/15 12:28:35 Done rebuilding.
+2015/03/15 12:28:35 HTTPS server started on 0.0.0.0:8443
+
+So you can now test to reach the server at port 8443, see a previous chapter about proper testing.
+
+Some remarks:
+- don't run the server daemon as root
+- every port between 1024 and 49151 is fine for i2p.
+- if you want to use the privileged (https-default) port 443, create a port redirect, e.g.
+    iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-port 8443
+- redirect the output from the go solution to a logfile, format is default apache-style combined logs
+- add a logrotate for the logfiles, since they grow big :-(
+- logfiles can be used by fail2ban
+- Both of the certificates (*.crt) will need to be sent to the reseed maintainer
+in order for your reseed server to be included in the standard I2P package.
+- Add a proper startup script, to run the reseed server, see next chapter
+
+
+
+
+-------------------------------------------------------------------------------
+22. matt's go solution - Draft for startup script
+
+The reseed server should be started automatically, so you need a init.d or some sort of startscript.
+This is only a very first draft for a simple startscript (it could be done better :-))
+The startscript can be placed in your personal crontab: @reboot   sleep 20 && /path_to/startscript
+
+
+Two logfiles are specified:
+ * reseed.log - apache-style combined logs
+ * reseed.error	- any error messages
+
+startscript:
+
+######################################################################################################
+#!/bin/sh
+
+export HOME=/home/i2puser
+export GOPATH=$HOME/go
+export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
+
+cd $GOPATH
+logfile=$HOME/go/reseed.log
+errfile=$HOME/go/reseed.error
+
+i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb >>$logfile 2>>$errfile &
+disown -h
+
+exit 0
+######################################################################################################
+
+
+
+
+-------------------------------------------------------------------------------
+23. matt's go solution - reverse-proxy setup
+
+You can run i2p-tools also behind your normal web-server (reverse-proxy).
+
+The web-server handles the TLS handshake, encryption, SSL Certificate and the logfiles.
+But you don't need the scripts su3.php and the shell cronjob for creating su3-files.
+i2p-tools is running "behind" the web-server, without TLS management, only bind to
+local interface 127.0.0.1 and is handling complete building and handling of su3-files.
+
+
+Run i2p-tools with this command:
+
+i2p-tools reseed --signer test@test.de --key /path_to/test_at_test.de.pem --netdb /path_to/netDb --port=8443 --ip 127.0.0.1 --trustProxy
+
+Important notes for this special setup:
+ * do *not* specify  --tlsHost, --tlsCert or --tlsKey on the command-line
+ * "ip 127.0.0.1" binds the program only to local interface
+ * "trustProxy" uses the "X-Forwarded-For" to get the real client IP
+
+
+lighttpd configuration example:
+	server.modules += ( "mod_proxy" )
+	proxy.server = ( ".su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) )  )
+
+
+nginx configuration example:
+	location / {
+		proxy_pass http://127.0.0.1:8443;
+	}
+
+and for X-Forwarded-For:
+     proxy_set_header        X-Real-IP       $remote_addr;
+     proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
+
+
+
+
+-------------------------------------------------------------------------------
+24. matt's go solution - Convert existing java keystore to crt- and pem-file
+
+This describes how to convert your existing java keystore with your su3 signing key to a plain crt- and pem-file.
+This is only needed, when you already have a java keystore and want to use matt's go solution.
+If you create new keys+certs with matt's solution you can skip this chapter!
+
+Requirements:
+ * java keytool
+ * openssl
+ * and of course your secret password for the keystore
+
+Keep in mind: the java keystore has two passwords:
+ * the secret key password you have entered while creating your keystore the first time (SU3File keygen ...)
+ * and a "storage" password, which is most probably default "changeit".
+
+This works in a Ubuntu/Debian shell:
+
+######################################################################################################
+file="keystore.ks"
+pass_jks=changeit
+
+# List the keystore content, show the included (email) alias
+keytool -list -storepass $pass_jks -keystore $file
+
+# Convert jks --> pkcs12, specify the correct email alias (xxxxx@mail.i2p):
+keytool -importkeystore -srcalias xxxxx@mail.i2p -srckeystore $file -srcstoretype jks -srcstorepass $pass_jks -destkeystore ${file}.p12  -deststoretype pkcs12 -deststorepass $pass_jks -destkeypass $pass_jks
+
+# Show the pkcs12 content:
+openssl pkcs12 -passin pass:$pass_jks -in ${file}.p12 -nodes -info
+
+# Convert pkcs12 --> pem
+openssl pkcs12 -passin pass:$pass_jks -in ${file}.p12 -nodes -out ${file}.pem
+
+# Decrypt the pem
+openssl rsa  -in ${file}.pem -out xxxxx_at_mail.i2p.pem
+
+# Extract the certificate
+openssl x509 -in ${file}.pem -out xxxxx_at_mail.i2p.crt
+######################################################################################################
+
+
+
      + +{% endblock %} diff --git a/i2p2www/pages/site/get-involved/index.html b/i2p2www/pages/site/get-involved/index.html index d47799b3..56ba9f7f 100644 --- a/i2p2www/pages/site/get-involved/index.html +++ b/i2p2www/pages/site/get-involved/index.html @@ -74,6 +74,11 @@ Both anonymity vulnerabilities from the various and DOS and other weaknesses due to securities holes, need researching. {%- endtrans %} +
    • {{ _('Reseeding') }} — +{% trans reseed=site_url('get-involved/guides/reseed') -%} +Set up a reseed server for new routers to bootstrap from. +Detailed instructions are on our reseed server page. +{%- endtrans %}
    • {{ _('Donate') }}
    From b74cb41e017301f9c1a654aea9d94feb6a02617e Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 6 Dec 2015 20:17:18 +0000 Subject: [PATCH 052/114] format fix --- i2p2www/pages/site/get-involved/guides/reseed.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index d42eb4d0..25d19e03 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -214,7 +214,7 @@ one su3-file within 24h for one client IP. 2. Requirements Requirements for running a public reseed server: -- well integrated running i2p router @ 24/7 {% endblock %} +- well integrated running i2p router @ 24/7 - server with static IPv4 (2 cpu/ 2GB ram is already fine) - unix to run the shell script, cronjobs or matts solution - own domain, a third level domain is fine too and may provide you with more anonymity. From 5188575c0a47d164ce3cb1974c3730485d4a0a57 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 8 Dec 2015 21:43:28 +0000 Subject: [PATCH 053/114] html-ize the reseed details --- .../site/get-involved/guides/reseed.html | 720 +++++++++++------- 1 file changed, 445 insertions(+), 275 deletions(-) diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index 25d19e03..64fc6a87 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -29,7 +29,7 @@ You must have a secure SSL setup with either a self-signed certificate or a cert The SSL configuration must conform to current best practices on allowed ciphers and protocols, and the CN/SAN host name must match the URL {%- endtrans %}
  • {% trans -%} -The scripts are designed to deliver different router info bundles to different requestors for nextwork diversity +The scripts are designed to deliver different router info bundles to different requestors for network diversity {%- endtrans %}
  • {% trans -%} The scripts are designed to deliver the same bundle to the same repeated requestor to prevent scraping @@ -68,7 +68,7 @@ Unfortunately, he is not generally on IRC. The reseed setup is somewhat speciali {%- endtrans %}

    {% trans -%} -For actual implementation, details are at the links below. In summary, there are two solutions we have to offer: +For actual implementation, details below. In summary, there are two solutions we have to offer: {%- endtrans %}

      @@ -93,18 +93,18 @@ Thank you!
    1. Go reseed server source on github
    2. -SU3 Reseed File Format Sspecification" +SU3 Reseed File Format Sspecification

      3. {% trans %}Detailed Instructions{% endtrans %}

      + +

      Revision History

       
-
--------------------------------------------------------------------------------
 2015-05-09 backup
  * new chapter: reverse-proxy setup (idea by kytv and review from matt)
- * ==> howto_public_reseed_server_v6.txt
+ * ==> howto_public_reseed_server_v6.txt
 
 2015-03-23 backup (with much help from matt)
  * Script - su3.php - added support for running INSIDE i2p-net (DESTB32)
@@ -117,14 +117,14 @@ Thank you!
  * new chapter: matt's go solution - Run the reseed server
  * new chapter: matt's go solution - Draft for startup script
  * new chapter: matt's go solution - Convert existing java keystore to crt- and pem-file
- * ==> howto_public_reseed_server_v5.txt
+ * ==> howto_public_reseed_server_v5.txt
 
 2015-01-22 backup	
  * Script - cronjob_i2p.sh - minor code cleanups with shell script validator/parser
  * Script - su3.php - minor code cleanup (404 redirect), thanks to "drgr33n"
  * we want only HTTPS accessible reseed server
  * Testings - added some wget options for the ssl-certificate, thanks to "drgr33n"
- * ==> howto_public_reseed_server_v4.txt
+ * ==> howto_public_reseed_server_v4.txt
 
 2014-12-26 backup
  * Script - cronjob_i2p.sh - config variable "target" without ending "/"
@@ -132,98 +132,105 @@ Thank you!
  * new chapter: reseed server domain/url/port exchange
  * chapter "requirements" expanded - traffic volume, attacks, webserver-port!=443
  * chapter "Create self-signed ssl-certificate" - use rsa, not ecdsa
- * ==> howto_public_reseed_server_v3.txt
+ * ==> howto_public_reseed_server_v3.txt
 
 2014-12-13 backup
  * new chapter: Create self-signed ssl-certificate
  * new chapter: Seamless ssl-cert exchange
  * meeh's solution removed
  * cronjob_i2p.sh: example target path changed to "/var/www/su3/" for clarification
- * ==> howto_public_reseed_server_v2.txt
+ * ==> howto_public_reseed_server_v2.txt
 
 2014-10-17 backup
  * initial release v1
 
+
      + + +

      How-to Public reseed servers - su3

      + +
        +
      • Some parts of this how-to are copied from zzz.i2p and are modified. +
      • Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to. +
      • Questions can be placed on zzz.i2p - in the Reseeding sub-forum. +
      -------------------------------------------------------------------------------- -How-to Public reseed servers - su3 +

      Table of contents

      -- Some parts of this how-to are copied from http://zzz.i2p and are modified. -- Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to. -- Questions can be placed on http://zzz.i2p/forums/18 - in the Reseeding sub-forum. +
        +
      1. Intro +
      2. Requirements +
      3. Short overview +
      4. su3-file guidelines for reseeding +
      5. How to prepare your key pair for su3-files +
      6. su3 server-side implementation +
      7. unix shell script for cronjob +
      8. Setup cronjob +
      9. php script for webserver +
      10. url rewrite rule for webserver +
      11. Create self-signed ssl-certificate +
      12. Seamless ssl-certificate exchange +
      13. reseed server domain/url/port exchange +
      14. Testings +
      15. Contact reseed maintainer +
      16. Script - cronjob_i2p.sh +
      17. Script - su3.php +
      18. Optional - setup a manual reseed method +
      19. matt's go solution - Overview +
      20. matt's go solution - Building from source +
      21. matt's go solution - Run the reseed server +
      22. matt's go solution - Draft for startup script +
      23. matt's go solution - reverse-proxy setup +
      24. matt's go solution - Convert existing java keystore to crt- and pem-file +
      - -------------------------------------------------------------------------------- -0. Table of contents - -1. Intro -2. Requirements -3. Short overview -4. su3-file guidelines for reseeding -5. How to prepare your key pair for su3-files -6. su3 server-side implementation -7. unix shell script for cronjob -8. Setup cronjob -9. php script for webserver -10. url rewrite rule for webserver -11. Create self-signed ssl-certificate -12. Seamless ssl-certificate exchange -13. reseed server domain/url/port exchange -14. Testings -15. Contact reseed maintainer -16. Script - cronjob_i2p.sh -17. Script - su3.php -18. Optional - setup a manual reseed method -19. matt's go solution - Overview -20. matt's go solution - Building from source -21. matt's go solution - Run the reseed server -22. matt's go solution - Draft for startup script -23. matt's go solution - reverse-proxy setup -24. matt's go solution - Convert existing java keystore to crt- and pem-file - - - - -------------------------------------------------------------------------------- -1. Intro - +

      1. Intro

      +

      Public reseed servers are necessary to bootstrap into the i2p net. New installed i2p routers needs one-time a handful RouterInfo's (RI) as jump start. +

      RI contains IP and Port from other i2p-routers and are stored in dat-files in the netDB folder. +

      A random bunch of dat-files from the netDB are zipped, then signed to a su3-file and finally offered to i2p-routers seeking reseed service. +

      To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory. +

      It is essential not to publish all RI from netDB, or all RI to one client. So a cronjob will be setup providing only a part of all available RI. +

      A php script ensures that requests to the public reseed server provides only one su3-file within 24h for one client IP. +

      +

      2. Requirements

      -------------------------------------------------------------------------------- -2. Requirements - +

      Requirements for running a public reseed server: -- well integrated running i2p router @ 24/7 -- server with static IPv4 (2 cpu/ 2GB ram is already fine) -- unix to run the shell script, cronjobs or matts solution -- own domain, a third level domain is fine too and may provide you with more anonymity. -- a self signed ssl-certificate is ok -- web-space (HTTPS only) with php5+rewrite-rule -- HTTPS only, with TLS 1.2, only with good ciphers -- enough bandwidth and traffic volume (due to a annoying botnet expect up to 1TB per month) -- fail2ban to protect you from the botnet +

        +
      • well integrated running i2p router @ 24/7 +
      • server with static IPv4 (2 cpu/ 2GB ram is already fine) +
      • unix to run the shell script, cronjobs or matts solution +
      • own domain, a third level domain is fine too and may provide you with more anonymity. +
      • a self signed ssl-certificate is ok +
      • web-space (HTTPS only) with php5+rewrite-rule +
      • HTTPS only, with TLS 1.2, only with good ciphers +
      • enough bandwidth and traffic volume (due to a annoying botnet expect up to 1TB per month) +
      • fail2ban to protect you from the botnet +
      +

      This How-to is tested with Ubuntu/Debian The web-space has to be public reachable from all over the world, an eepsite inside i2p can be setup in addition. Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server. @@ -232,64 +239,81 @@ The webserver doesn't need to listen at default SSL/TSL port 443 - any other por -------------------------------------------------------------------------------- -3. Short overview +

      3. Short overview

      -- permanent: run your i2p router -- once: generate a private and public key pair for signing the reseed files -- once: setup the php script on the web-space -- once: setup a rewrite rule at webserver (*.su3 --> su3.php) -- regularly: run the unix shell script to generate up-to-date su3-files -- regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web-space +
        +
      • permanent: run your i2p router +
      • once: generate a private and public key pair for signing the reseed files +
      • once: setup the php script on the web-space +
      • once: setup a rewrite rule at webserver (*.su3 --> su3.php) +
      • regularly: run the unix shell script to generate up-to-date su3-files +
      • regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web-space +
      +

      4. su3-file guidelines for reseeding

      -------------------------------------------------------------------------------- -4. su3-file guidelines for reseeding - -(From http://zzz.i2p/topics/1648) -- The su3-file must be named "i2pseeds.su3" -- The file must be in the same directory as the routerinfos on the web server -- Router will first try to fetch (index url)/i2pseeds.su3; +

      +(From zzz.i2p) +

        +
      • The su3-file must be named "i2pseeds.su3" +
      • The file must be in the same directory as the routerinfos on the web server +
      • Router will first try to fetch (index url)/i2pseeds.su3; if that fails it will fetch (index url) and then fetch the individual RI files, old-style -- Once a reseed from a host succeeds, it won't try any other URLs from that host +
      • Once a reseed from a host succeeds, it won't try any other URLs from that host (either http or https, ignoring ports... ports are now implemented) -- RI files in the zip file (in the su3-file) must be at the "top level", +
      • RI files in the zip file (in the su3-file) must be at the "top level", i.e. no directories in the zip file -- su3 content type must be RESEED (-c 3 or -c RESEED) -- su3 signature type should be RSA 4096 (-t 6 or -t RSA_SHA512_4096). +
      • su3 content type must be RESEED (-c 3 or -c RESEED) +
      • su3 signature type should be RSA 4096 (-t 6 or -t RSA_SHA512_4096). If you're very low on CPU power you could use a shorter key, but you only need to do the signing process once a day or so. Any sig type will work, but RSA 4096 is the best in this case. -- Of course we must have your su3 signing public key checked in +
      • Of course we must have your su3 signing public key checked in under the same name as you are using in the signing process, e.g. for you@mail.i2p the file name must be you_at_mail.i2p.crt, in the certificates/reseed/ directory +
      +

      5. How to prepare your key pair for su3-files

      -------------------------------------------------------------------------------- -5. How to prepare your key pair for su3-files +

      +( from zzz.i2p) +

        +
      • Details are posted here from zzz: zzz.i2p +
      • Who? All owner of a public reseed server. +
      • Why? su3 reseed files will be signed with your private key. +
      • This ensures a secure bootstrap for i2p routers. +
      • Corresponding public keys will be included in i2p router package. +
      -( from http://zzz.i2p/topics/1643) -Details are posted here from zzz: http://zzz.i2p/topics/1473 -Who? All owner of a public reseed server. -Why? su3 reseed files will be signed with your private key. -This ensures a secure bootstrap for i2p routers. -Corresponding public keys will be included in i2p router package. +

      Example to create your key pair: +

       	su - i2puser
 	I2P=/home/i2puser/i2p
 	cd $I2P
 	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File keygen -t RSA_SHA512_4096 backup_at_mail.i2p.crt keystore.ks backup@mail.i2p
+
      +

      Short usage help: +

       	SU3File keygen [-t type|code] publicKeyFile keystore.ks you@mail.i2p
+
      +

      Get more help: +

       	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File
+
      +

      Provide a strong password for your private key. In this example two new files will be created in the working folder: -- backup_at_mail.i2p.crt will contain the public key -- keystore.ks is the Java keystore file and contains your private key +

        +
      • backup_at_mail.i2p.crt will contain the public key +
      • keystore.ks is the Java keystore file and contains your private key +
      +

      Backup and store public key, private key and your password! Remember also the used key size/type when not using default RSA_SHA512_4096. Send the public .crt key file to us, to include it into i2p/certificates/reseed/ @@ -300,66 +324,81 @@ There is no requirement that it be xxx@mail.i2p, any email is fine, or for that -------------------------------------------------------------------------------- -6. su3 server-side implementation - -(from http://zzz.i2p/topics/1647) +

      6. su3 server-side implementation

      + +

      +(from zzz.i2p) This describes a mechanism for creating and distributing the RI in new su3 format. It's independent from legacy way of doing (fetching dat-files) and can be used in parallel. This idea don't need mysql, only some Unix shell tools and a simple web-space with php works fine. +

      A requesting client gets ~75 RI packed into one zip, signed and converted to a su3-file. Don't provide unlimited RI to one clients. But don't try to keep track of million client IP's in a database, e.g think of ipv6. -Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo. +Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo. n is the unlimited IPv4+IPv6 address space, and m are e.g. 100 pre-calculated su3-files. A client with one IP gets always the same su3-file, until the su3-file is updated or the client has a new IP. A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in i2p net grow. +

      Once or twice a week (or daily): pre-calculate ~100 new su3-files, each includes ~75 RI. The RI are fetched from a well running i2p router's netdb directory. Transfer the pre-calculate su3-files to your web-space, e.g. by sftp or copy them locally to /var/www/su3/. In the web-space a php script will match one client IP to one of the 100 su3-files by hash+modulo. This has the advantage to split su3-generation and publishing in web-space . +

      Requirements for su3-file generation: -- 24/7 running i2p-router with up to date netdb -- ziptool, e.g. "zip" (Debian/Ubuntu: sudo apt-get install zip) -- Unix shell: find, awk, cat, ... -- your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password +

        +
      • 24/7 running i2p-router with up to date netdb +
      • ziptool, e.g. "zip" (Debian/Ubuntu: sudo apt-get install zip) +
      • Unix shell: find, awk, cat, ... +
      • your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password +
      Requirements for web-space : -- php5 -- rewrite rule (*.su3 --> php) +
        +
      • php5 +
      • rewrite rule (*.su3 --> php) +
      The following solution for a public reseed server consists of three parts: -- unix shell script for cronjob -- php script -- url rewrite rule +
        +
      • unix shell script for cronjob +
      • php script +
      • url rewrite rule +
      They are described on the following chapters in more detail. -------------------------------------------------------------------------------- -7. unix shell script for cronjob +

      7. unix shell script for cronjob

      +

      This script pre-calculates n su3-files. Requirements: unix shell, java, i2p, zip-tool, your private reseed signing key Main Steps: +

       # CONFIG
 # CHECK REQUIREMENT
 # CREATE index files from netdB: use only 66% and max. 10h old
 # CREATE zip files
 # CREATE su3 files
 # FINALIZE
+
      +

      Please check and edit #CONFIG sections, please review code before use. The resulting su3-files are placed in the "target" folder which can be changed in config section with "target". Configure file permissions and file owner e.g. 'www-data' - see deactivated example lines. The cronjob script runs ca. 10 seconds for generating 100 pre-calculated su3 files on a modern cpu. The number of dat-files per su3 package is random. If you configure 75, it results in ca. 50...100 dat-files per su3-file. The number of generated su3-files is random too, it depends on your netdb size and adapts automatically: -- 1000 netdb entries: used for publishing: ~666, results in ~66 su3-files, each with ~75 dat-files -- 3000 netdb entries: used for publishing: ~1999, results in ~199 su3-files, each with ~75 dat-files +

        +
      • 1000 netdb entries: used for publishing: ~666, results in ~66 su3-files, each with ~75 dat-files +
      • 3000 netdb entries: used for publishing: ~1999, results in ~199 su3-files, each with ~75 dat-files +
      +

      Only 66% of all RI from your netdb are used, netdb may be not older than 10h. It is possible to separate cronjob script from php script: Run the cronjob script on your i2p machine and then transfer the final su3-files via (s)ftp/ssh @@ -368,79 +407,102 @@ to your webserver from time to time. su3 file-size in this setup is between 50 a -------------------------------------------------------------------------------- -8. Setup cronjob +

      8. Setup cronjob

      +

      Please add a cronjob, e.g. to run it every few days. Add the shell script in crontab, e.g.: +

       	crontab -e
 	23 59 * * * /usr/local/bin/cronjob_i2p.sh
+
      +

      The hard limit for the su3-file age is 30 days. Recommendation is to update the su3-files once every 1..10 days. -------------------------------------------------------------------------------- -9. php script for webserver +

      9. php script for webserver

      +

      The su3.php script maps always one client IP to one pre-calculated su3-file. Requirements: a webserver with php5 Main Steps: +

       # CONFIG
 # HEALTH CHECK
 # COUNT su3 files
 # MAPPING Client IP to one SU3
 # PROVIDE SU3
+
      +

      Please check and edit #CONFIG sections, please review code before use. +

      The date() function in the salt ensures a rotate once a day, even if su3-files are not updated daily. To avoid scraping from attackers with big IPv4 subnet resources (or even IPv6) some lower bytes of the client IP address are discarded: -- IPv4: 4 byte --> 1 lowest byte -- IPv6: 16 bytes --> 8 lowest bytes +

        +
      • IPv4: 4 byte --> 1 lowest byte +
      • IPv6: 16 bytes --> 8 lowest bytes +
      Clients in the same "subnet" gets the same su3-file +

      A clients gets only different su3-file package in following circumstances: -- when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address) -- at 00:00 every date (date function in php) -- when the unix cronjob updates the su3 files +

        +
      • when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address) +
      • at 00:00 every date (date function in php) +
      • when the unix cronjob updates the su3 files +
      -------------------------------------------------------------------------------- -10. url rewrite rule for webserver +

      10. url rewrite rule for webserver

      +

      It is mandatory that clients does not have direct access to the su3-files at the webserver. Please activate a rewrite rule for su3-files in your webserver pointing to the su3.php file: - *.su3 --> su3.php?file=$1 +

      +	*.su3 --> su3.php?file=$1
+
      +

      Apache in ".htaccess": +

       	Options +FollowSymlinks
 	RewriteEngine On
 	RewriteRule ^(.*\.su3)$ /su3.php?file=$1 [L]
+
      +

      lighttpd in "/etc/lighttpd/lighttpd.conf": +

       	server.modules += ( "mod_rewrite" )
-	url.rewrite-once = ( "^(.*\.su3)$" => "/su3.php?file=$1" )
+	url.rewrite-once = ( "^(.*\.su3)$" => "/su3.php?file=$1" )
+
      +

      We want only HTTPS accessible reseed server. Sorted by best solution: - * please deactivate plain HTTP, or - * use a redirect rule in your webserver, or - * implement the redirect to HTTPS in the php-code +

        +
      • please deactivate plain HTTP, or +
      • use a redirect rule in your webserver, or +
      • implement the redirect to HTTPS in the php-code +
      +

      11. Create self-signed ssl-certificate

      -------------------------------------------------------------------------------- -11. Create self-signed ssl-certificate - +

      How-to generate a new self-signed ssl-certificate for HTTPS/TLS with openssl. Example command line in Debian/Ubuntu for your.server.com: +

       $ openssl req -x509 -nodes -days 1500 -newkey rsa:4096 -sha256 -keyout your.server.com.pem -out your.server.com.pem
 ...
 Country Name (2 letter code) [AU]:UK
@@ -450,120 +512,150 @@ Organization Name (eg, company) [Internet Widgits Pty Ltd]:your.server.com
 Organizational Unit Name (eg, section) []:your.server.com
 Common Name (e.g. server FQDN or YOUR name) []:your.server.com
 Email Address []:your.server.com
+
      ---> The result is stored in "your.server.com.pem" file +

      +The result is stored in "your.server.com.pem" file +

      Remarks: -- Please fill out all fields, don't use blanks -- rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu -- use rsa, not ecdsa (ecdsa will break currently RetHat users) -- days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years)) -- sha256 - important, without this option openssl currently uses weak sha1 by default -- Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup. +

        +
      • Please fill out all fields, don't use blanks +
      • rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu +
      • use rsa, not ecdsa (ecdsa will break currently RetHat users) +
      • days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years)) +
      • sha256 - important, without this option openssl currently uses weak sha1 by default +
      • Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup. +
      +

      Next step: -- Open the created pem-file with a simple text editor. -- You see the section with the private key and the section with the public key. -- Copy the public section (starting with -----BEGIN CERTIFICATE-----) to another new file -- and save the new file as your.server.com.crt file ---> Send this to us - the .crt file with the public key section will we included in every i2p router. ---> The .pem file with your private key is only for you and your webserver. +

        +Open the created pem-file with a simple text editor. +You see the section with the private key and the section with the public key. +Copy the public section (starting with -----BEGIN CERTIFICATE-----) to another new file +and save the new file as your.server.com.crt file +
      + +

      +Send this to us - the .crt file with the public key section will we included in every i2p router. +The .pem file with your private key is only for you and your webserver. -------------------------------------------------------------------------------- -12. Seamless ssl-certificate exchange +

      12. Seamless ssl-certificate exchange

      +

      The update/exchange of an already existing self-signed certificates has to be correct timed on server *and* client side. Considering thousands of clients (many with older i2p version) the exchange will not be seamless possible and will have very bad impact on many clients: reseed won't work for them. +

      To avoid this issue and make the exchange as smooth as possible follow these simple steps: -1. generate a new ssl-certificate NOW, but do NOT implement it on server -2. send the new ssl-certificate to us to perform a roll-out towards clients NOW -3. WAIT some month, e.g. 3-4 i2p-releases -4. new ssl-certificate is now hopefully present on many clients (in parallel to the current/old one) -5. THEN exchange the ssl-certificate on server +

        +
      1. generate a new ssl-certificate NOW, but do NOT implement it on server +
      2. send the new ssl-certificate to us to perform a roll-out towards clients NOW +
      3. WAIT some month, e.g. 3-4 i2p-releases +
      4. new ssl-certificate is now hopefully present on many clients (in parallel to the current/old one) +
      5. THEN exchange the ssl-certificate on server +
      +

      This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g. server.com.crt and server.com2.crt -------------------------------------------------------------------------------- -13. reseed server domain/url/port exchange +

      13. reseed server domain/url/port exchange

      +

      You are already operating a reseed server but want to change your domain/url/port? To make the exchange as smooth as possible for many clients please follow these steps if possible: -a) Setup an additional reseed instance at the new domain/url/port -b) we include the new url into i2p source NOW and delete the old url NOW -c) both of your reseed instances have to run some time in parallel -d) WAIT some month, e.g. 3-4 i2p-releases -e) new url is now hopefully present on many clients -f) THEN shutdown the old reseed instance +

        +
      1. Setup an additional reseed instance at the new domain/url/port +
      2. we include the new url into i2p source NOW and delete the old url NOW +
      3. both of your reseed instances have to run some time in parallel +
      4. WAIT some month, e.g. 3-4 i2p-releases +
      5. new url is now hopefully present on many clients +
      6. THEN shutdown the old reseed instance +
      +

      14. Testings

      -------------------------------------------------------------------------------- -14. Testings - +

      Some simple pre-test: test the website and fetch +

       	wget --user-agent="Wget/1.11.4" -O /tmp/test.su3 --no-check-certificate https://your-server.com:PORT/i2pseeds.su3
+
      Replace "PORT" with default 443 or your chosen server setting. Inspect the fetched file: +Some simple pre-test: test the website and fetch zipinfo -z /tmp/test.su3 + +

      Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt" which contains the path to your local public ssl-certificate to check also your ssl-certificate chain. +

      Everything ok: -- ssl-certificate chain valid? -- The su3-files can be downloaded? -- contains >50 dat-files? -- and is always the same for one client-IP? -- other client-IP's gets another file? -- Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ? +

        +
      • ssl-certificate chain valid? +
      • The su3-files can be downloaded? +
      • contains >50 dat-files? +
      • and is always the same for one client-IP? +
      • other client-IP's gets another file? +
      • Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ? +
      +

      Do a real reseed test on *another* i2p router machine: -- include manually new ssl-certificate into i2p installation: ~/i2p/certificates/ssl/ -- include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/ -- http://localhost:7657/configreseed --> remove all reseed hosts -- add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3" -- Save and Shutdown router. -- clear netdb: empty folder ./i2p/netDb. -- Restart i2p and watch the i2p router log: +

        +
      • include manually new ssl-certificate into i2p installation: ~/i2p/certificates/ssl/ +
      • include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/ +
      • http://localhost:7657/configreseed --> remove all reseed hosts +
      • add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3" +
      • Save and Shutdown router. +
      • clear netdb: empty folder ./i2p/netDb. +
      • Restart i2p and watch the i2p router log: +
         2014/10/13 23:01:02 | Reseed start
 2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
 2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
 2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
 2014/10/13 23:01:06 | Reseed complete, xx received
+
        +
      -------------------------------------------------------------------------------- -15. Contact reseed maintainer +

      15. Contact reseed maintainer

      +

      Contact us per email backup@mail.i2p (fallback is killyourtv@mail.i2p or the reseed section at zzz's forum) Provide us details about the new - - reseed website url, - - public part of ssl-certificate - - public su3-key - - your contact email +

        +
      • reseed website url, +
      • public part of ssl-certificate +
      • public su3-key +
      • your contact email +
      +

      Feel free to contact backup@mail.i2p in case of questions or problems or post your question at zzz's forum in the reseed section. -------------------------------------------------------------------------------- -16. Script - cronjob_i2p.sh - +

      16. Script - cronjob_i2p.sh

      +
       ###############################################################################
 #!/bin/sh
 version="v5"
@@ -612,10 +704,10 @@ find "${source}" -type f -mmin -600 -name 'routerInfo-*.dat' | awk -v ri_seed="$
 		ri_su3=int(ri_use/10);
 		stepy=ri_use/ri_all;
 		stepx=ri_seed/ri_use;
-		for (y=0;y> file
+				print data[y] >> file
 			}
 		}
 	}'
@@ -623,7 +715,7 @@ find "${source}" -type f -mmin -600 -name 'routerInfo-*.dat' | awk -v ri_seed="$
 
 # CREATE zip-files from index-files
 find "${target_tmp}" -type f -name '*.index' | sort | while read i; do
-	"${tool_zip}" --update --quiet --junk-paths "${target_tmp}/$(basename "$i" .index)" -@ < "$i"
+	"${tool_zip}" --update --quiet --junk-paths "${target_tmp}/$(basename "$i" .index)" -@ < "$i"
 done
 
 
@@ -655,15 +747,14 @@ echo      "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
 logger -t "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
 exit 0
 ###############################################################################
+
      - -------------------------------------------------------------------------------- -17. Script - su3.php - +

      17. Script - su3.php

      +
       ###############################################################################
-8) { $shrink=8; };
+$shrink=3; if (strlen($remote_id)>8) { $shrink=8; };
 $remote_id = abs(crc32(md5(substr($remote_id,0,$shrink).$salt))) % $count_su3;
 $file_id = $path_su3."/".$remote_id.".su3";
 
@@ -723,192 +814,247 @@ header('Content-Disposition: attachment; filename='.$file_su3);
 ob_clean(); flush();
 if (!readfile($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
 exit;
-?>
+?>
 ###############################################################################
+
      - -------------------------------------------------------------------------------- -18. Optional - setup a manual reseed method - +

      18. Optional - setup a manual reseed method

      +

      For some users the automated reseeding may not work. This is an alternate way for users to get a valid reseed file with a normal web-browser, e.g. from another machine or maybe a friend. It is secured by a captcha to prevent abuse. +

      With this optional code users can visit https://your.reseedserver.com/reseed.php with any web-browser to download a su3-file after they solved the captcha. +

      Since 0.9.18-9 I2P has support to use reseed files from other sources: http://localhost:7657/configreseed +

      Visit https://geti2p.net/en/faq#manual_reseed to read how it works for users and see some example url's. -[NOT DONE YET: read here: http://zzz.i2p/topics/1828-running-prototype-manually-reseed-captcha -or test here anonymously: http://reseed.i2p/open.php] +[NOT DONE YET: read here: zzz.i2p +or test here anonymously: reseed.i2p] +

      The changes for an exiting reseed server with the previous setup are simple: -- use the latest su3.php from above (minimal version 5, only minor changes, no change of logic). -- add the new reseed.php to your /var/www folder, next to to su3.php -- install php5-gd (restart of php processes may be necessary) -- get Securimage php-code from https://www.phpcaptcha.org/ +

        +
      • use the latest su3.php from above (minimal version 5, only minor changes, no change of logic). +
      • add the new reseed.php to your /var/www folder, next to to su3.php +
      • install php5-gd (restart of php processes may be necessary) +
      • get Securimage php-code from https://www.phpcaptcha.org/ +
      +

      Quote from https://www.phpcaptcha.org (2015-03): "Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots. It can run on most any webserver as long as you have PHP installed, and GD support within PHP. Securimage does everything from generating the CAPTCHA images to validating the typed code." +

      Short overview about installing Securimage: - 1. download at https://www.phpcaptcha.org/download/ - 2. extract to /var/www/securimage - 3. download and extract the "Test Script" (securimage_test.php) from the same url - 4. test your server and visit https://.../securimage_test.php with your browser +

        +
      1. download at https://www.phpcaptcha.org/download/ +
      2. extract to /var/www/securimage +
      3. download and extract the "Test Script" (securimage_test.php) from the same url +
      4. test your server and visit https://.../securimage_test.php with your browser +
      +

      The "Test Script" verifies your ability to run and display the captcha code, and can be deleted after the test. +

      The reseed.php contains only the captcha generation and verification of the users input. It is based on the Quickstart Guide from Securimage. When the user solved the captcha, reseed.php sets two http variables and then includes the external su3.php to start the su3-file download. +

      The name "reseed.php" is not fixed, you can name it unremarkable/unobtrusive as you like, enter.php start.php go.php... but you have to stick with it, when it is published :-) +

      reseed.php: +

       ################################################################################################
-
-
-check($_POST['captcha_code']) == false) {?>
-	
      
-	CAPTCHA Image
-	
      Enter Code: 
-	
-	
      
-
-
+} ?>
+</body></html>
 ################################################################################################
+
      +

      19. matt's go solution - Overview

      -------------------------------------------------------------------------------- -19. matt's go solution - Overview - +

      The previous steps for reseeding involves many steps, scripts and programs. Most of them are easy and plain straight forward, but overall you can call it a little confusing. +

      Here comes now an all-in-one solution from matt (Big Thanks!) for providing a reseed server which merges the following functions into one binary: -- create su3-files -- create su3 signer certificate+key -- create ssl-certificate+key -- replaces the http-server and the php code (or run next to them in parallel) +

        +
      • create su3-files +
      • create su3 signer certificate+key +
      • create ssl-certificate+key +
      • replaces the http-server and the php code (or run next to them in parallel) +
      +

      Almost all previous used scripts and described steps are not needed with this solution, but to understand the overall reseed process it is recommended to read them too :-) - - If you already have an ssl-certificate and su3-signer-key you can reuse them, see one of the following chapter. - - For testing and new reseeders the required certs and keys are created automatically at first start. - - Also take a look at the content and the naming scheme of these pem and crt files. +

        +
      • If you already have an ssl-certificate and su3-signer-key you can reuse them, see one of the following chapter. +
      • For testing and new reseeders the required certs and keys are created automatically at first start. +
      • Also take a look at the content and the naming scheme of these pem and crt files. +
      +

      Of course you need an up-to-date netDB folder with routerinfos from a running i2p router. I2P does not have to be running on the same machine as this reseed binary. In this case you can setup a cronjob to transfer the netDB from the I2P machine to the reseed machine. +

      Matt's go solution can be used in parallel next to an already running http-server. For this leave the http-server running at normal port 80 and 443, and configure matt's go solution too use another port, e.g. port 8443. +

      More: at github, README.md, https://github.com/MDrollette/i2p-tools -------------------------------------------------------------------------------- -20. matt's go solution - Building from source +

      20. matt's go solution - Building from source

      +

      Requirements: - - go1.4.2 (older versions may not work) +

        +
      • go1.4.2 (older versions may not work) +
      +

      Install go from https://golang.org/doc/install, example for 64 bit Ubuntu/Debian: - - wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz - - sudo tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz - - mkdir $HOME/go - - edit /etc/profile and add: +

        +
      • wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz +
      • sudo tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz +
      • mkdir $HOME/go +
      • edit /etc/profile and add: +
         	export GOPATH=$HOME/go
 	export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
+
        +
      +

      Verify go: +

       $ go version
+
      which should state something like: "go version go1.4.2" +

      Install matt's go solution from https://github.com/MDrollette/i2p-tools into $HOME/go: +

       $ go get github.com/MDrollette/i2p-tools
+
      +

      This will install a binary to $GOPATH/bin/i2p-tools +

      Run the go solution, the usage/help should be displayed, nothing more: +

       $ i2p-tools
+
      -------------------------------------------------------------------------------- -21. matt's go solution - Run the reseed server +

      21. matt's go solution - Run the reseed server

      +
       $ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb
+
      -- replace myserver.com with your real domain -- replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose -- new TLS certificate+key will be created (if they do not exist) -- new signing certificate+key will be created (if they do not exist) -- netdb=... should point to the netdb folder of your running i2p with the routerinfos -- to use another port append "--port=443" to the command, default is port 8443 +
        +
      • replace myserver.com with your real domain +
      • replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose +
      • new TLS certificate+key will be created (if they do not exist) +
      • new signing certificate+key will be created (if they do not exist) +
      • netdb=... should point to the netdb folder of your running i2p with the routerinfos +
      • to use another port append "--port=443" to the command, default is port 8443 +
      +

      Output: +

       2015/03/15 12:28:25 Rebuilding su3 cache...
 2015/03/15 12:28:25 Building 200 su3 files each containing 75 out of 3180 routerInfos.
 2015/03/15 12:28:35 Done rebuilding.
 2015/03/15 12:28:35 HTTPS server started on 0.0.0.0:8443
+
      +

      So you can now test to reach the server at port 8443, see a previous chapter about proper testing. +

      Some remarks: -- don't run the server daemon as root -- every port between 1024 and 49151 is fine for i2p. -- if you want to use the privileged (https-default) port 443, create a port redirect, e.g. +

        +
      • don't run the server daemon as root +
      • every port between 1024 and 49151 is fine for i2p. +
      • if you want to use the privileged (https-default) port 443, create a port redirect, e.g. iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-port 8443 -- redirect the output from the go solution to a logfile, format is default apache-style combined logs -- add a logrotate for the logfiles, since they grow big :-( -- logfiles can be used by fail2ban -- Both of the certificates (*.crt) will need to be sent to the reseed maintainer +
      • redirect the output from the go solution to a logfile, format is default apache-style combined logs +
      • add a logrotate for the logfiles, since they grow big :-( +
      • logfiles can be used by fail2ban +
      • Both of the certificates (*.crt) will need to be sent to the reseed maintainer in order for your reseed server to be included in the standard I2P package. -- Add a proper startup script, to run the reseed server, see next chapter +
      • Add a proper startup script, to run the reseed server, see next chapter +
      -------------------------------------------------------------------------------- -22. matt's go solution - Draft for startup script +

      22. matt's go solution - Draft for startup script

      +

      The reseed server should be started automatically, so you need a init.d or some sort of startscript. This is only a very first draft for a simple startscript (it could be done better :-)) The startscript can be placed in your personal crontab: @reboot sleep 20 && /path_to/startscript +

      Two logfiles are specified: - * reseed.log - apache-style combined logs - * reseed.error - any error messages +

        +
      • reseed.log - apache-style combined logs +
      • reseed.error - any error messages +
      +

      startscript: +

       ######################################################################################################
 #!/bin/sh
 
@@ -920,71 +1066,97 @@ cd $GOPATH
 logfile=$HOME/go/reseed.log
 errfile=$HOME/go/reseed.error
 
-i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb >>$logfile 2>>$errfile &
+i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb >>$logfile 2>>$errfile &
 disown -h
 
 exit 0
 ######################################################################################################
+
      -------------------------------------------------------------------------------- -23. matt's go solution - reverse-proxy setup +

      23. matt's go solution - reverse-proxy setup

      +

      You can run i2p-tools also behind your normal web-server (reverse-proxy). +

      The web-server handles the TLS handshake, encryption, SSL Certificate and the logfiles. But you don't need the scripts su3.php and the shell cronjob for creating su3-files. i2p-tools is running "behind" the web-server, without TLS management, only bind to local interface 127.0.0.1 and is handling complete building and handling of su3-files. +

      Run i2p-tools with this command: +

       i2p-tools reseed --signer test@test.de --key /path_to/test_at_test.de.pem --netdb /path_to/netDb --port=8443 --ip 127.0.0.1 --trustProxy
+
      Important notes for this special setup: - * do *not* specify --tlsHost, --tlsCert or --tlsKey on the command-line - * "ip 127.0.0.1" binds the program only to local interface - * "trustProxy" uses the "X-Forwarded-For" to get the real client IP +
        +
      • do *not* specify --tlsHost, --tlsCert or --tlsKey on the command-line +
      • "ip 127.0.0.1" binds the program only to local interface +
      • "trustProxy" uses the "X-Forwarded-For" to get the real client IP +
      + +"trustProxy" uses the "X-Forwarded-For" to get the real client IP +

      lighttpd configuration example: +

       	server.modules += ( "mod_proxy" )
-	proxy.server = ( ".su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) )  )
+	proxy.server = ( ".su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) )  )
+
      +

      nginx configuration example: +

       	location / {
 		proxy_pass http://127.0.0.1:8443;
 	}
+
      +

      and for X-Forwarded-For: +

            proxy_set_header        X-Real-IP       $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
+
      -------------------------------------------------------------------------------- -24. matt's go solution - Convert existing java keystore to crt- and pem-file +

      24. matt's go solution - Convert existing java keystore to crt- and pem-file

      +

      This describes how to convert your existing java keystore with your su3 signing key to a plain crt- and pem-file. This is only needed, when you already have a java keystore and want to use matt's go solution. If you create new keys+certs with matt's solution you can skip this chapter! +

      Requirements: - * java keytool - * openssl - * and of course your secret password for the keystore +

        +
      • java keytool +
      • openssl +
      • and of course your secret password for the keystore +
      +

      Keep in mind: the java keystore has two passwords: - * the secret key password you have entered while creating your keystore the first time (SU3File keygen ...) - * and a "storage" password, which is most probably default "changeit". +

        +
      • the secret key password you have entered while creating your keystore the first time (SU3File keygen ...) +
      • and a "storage" password, which is most probably default "changeit". +
      +

      This works in a Ubuntu/Debian shell: +

       ######################################################################################################
 file="keystore.ks"
 pass_jks=changeit
@@ -992,13 +1164,13 @@ pass_jks=changeit
 # List the keystore content, show the included (email) alias
 keytool -list -storepass $pass_jks -keystore $file
 
-# Convert jks --> pkcs12, specify the correct email alias (xxxxx@mail.i2p):
+# Convert jks --> pkcs12, specify the correct email alias (xxxxx@mail.i2p):
 keytool -importkeystore -srcalias xxxxx@mail.i2p -srckeystore $file -srcstoretype jks -srcstorepass $pass_jks -destkeystore ${file}.p12  -deststoretype pkcs12 -deststorepass $pass_jks -destkeypass $pass_jks
 
 # Show the pkcs12 content:
 openssl pkcs12 -passin pass:$pass_jks -in ${file}.p12 -nodes -info
 
-# Convert pkcs12 --> pem
+# Convert pkcs12 --> pem
 openssl pkcs12 -passin pass:$pass_jks -in ${file}.p12 -nodes -out ${file}.pem
 
 # Decrypt the pem
@@ -1007,8 +1179,6 @@ openssl rsa  -in ${file}.pem -out xxxxx_at_mail.i2p.pem
 # Extract the certificate
 openssl x509 -in ${file}.pem -out xxxxx_at_mail.i2p.crt
 ######################################################################################################
-
-
      {% endblock %} From 42b4bc8cf717cd7ad79e9041997862efd4481e12 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 11 Dec 2015 12:22:13 +0000 Subject: [PATCH 054/114] Update reseed detailed instructions to v7 Other reseed cleanup Note removal of old router info options in 0.9.24 Note Tor Messenger ports Update dates --- .../pages/site/docs/how/network-database.html | 8 +- i2p2www/pages/site/docs/index.html | 4 +- i2p2www/pages/site/docs/ports.html | 3 +- .../site/get-involved/guides/reseed.html | 327 +++++++++++++----- 4 files changed, 251 insertions(+), 91 deletions(-) diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index 2ce5d087..60bd79be 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}The Network Database{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}Nov. 2015{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} {% block accuratefor %}0.9.23{% endblock %} {% block content %}

      {% trans %}Overview{% endtrans %}

      @@ -62,7 +62,7 @@ For compatibility with older routers, a router may publish multiple bandwidth le
    3. coreVersion ({% trans %}The core library version, always the same as the router version{% endtrans %}) -(Unused, scheduled to be removed soon) +(Never used, scheduled to be removed in release 0.9.24)
    4. netId = 2 ({% trans %}Basic network compatibility - A router will refuse to communicate with a peer having a different netId{% endtrans %}) @@ -72,8 +72,8 @@ For compatibility with older routers, a router may publish multiple bandwidth le
    5. stat_uptime = 90m ({% trans %}Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime, -and only sent tunnel requests to peers whose was more than 60m{% endtrans %}) -(Unused, scheduled to be removed soon) +and only sent tunnel requests to peers whose uptime was more than 60m{% endtrans %}) +(Unused since version 0.7.9, scheduled to be removed in release 0.9.24)
      6. diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index 8eae8128..e59e8756 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}November 2014{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.17{% endblock %} +{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.23{% endblock %} {% block content %}

      {% trans -%} Following is an index to the technical documentation for I2P. diff --git a/i2p2www/pages/site/docs/ports.html b/i2p2www/pages/site/docs/ports.html index 514debab..191e0207 100644 --- a/i2p2www/pages/site/docs/ports.html +++ b/i2p2www/pages/site/docs/ports.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Ports Used by I2P{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}April 2015{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} {% block accuratefor %}0.9.19{% endblock %} {% block content %} @@ -61,6 +61,7 @@ in the 766x range. 8999Monotone Proxy (alt) 9050Tor SOCKS Proxy (reserve) 9051-9053SOCKS Proxy (typ) +9152-9153Tor Messenger Socks and Control ports (reserve) 9111-30777Network (random) 11371SKS/GPG Key Server (reserve) 31000Wrapper diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index 64fc6a87..9de92af4 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -102,6 +102,11 @@ Thank you!

      Revision History

       
+2015-10-08 backup
+* self-signed ssl-certificate with EC signature + key
+* updated start-script for matts solution - "seedserver"
+* ==> howto_public_reseed_server_v7.txt
+
 2015-05-09 backup
  * new chapter: reverse-proxy setup (idea by kytv and review from matt)
  * ==> howto_public_reseed_server_v6.txt
@@ -116,7 +121,7 @@ Thank you!
  * new chapter: matt's go solution - Building from source
  * new chapter: matt's go solution - Run the reseed server
  * new chapter: matt's go solution - Draft for startup script
- * new chapter: matt's go solution - Convert existing java keystore to crt- and pem-file
+ * new chapter: matt's go solution - Convert existing Java keystore to crt- and pem-file
  * ==> howto_public_reseed_server_v5.txt
 
 2015-01-22 backup	
@@ -130,7 +135,7 @@ Thank you!
  * Script - cronjob_i2p.sh - config variable "target" without ending "/"
  * meeh completely removed in contacts
  * new chapter: reseed server domain/url/port exchange
- * chapter "requirements" expanded - traffic volume, attacks, webserver-port!=443
+ * chapter "requirements" expanded - traffic volume, attacks, web server-port!=443
  * chapter "Create self-signed ssl-certificate" - use rsa, not ecdsa
  * ==> howto_public_reseed_server_v3.txt
 
@@ -166,10 +171,10 @@ Thank you!
 
    6. su3-file guidelines for reseeding
 
    7. How to prepare your key pair for su3-files
 
    8. su3 server-side implementation
-
    9. unix shell script for cronjob
+
    10. Unix shell script for cronjob
 
    11. Setup cronjob
-
    12. php script for webserver
-
    13. url rewrite rule for webserver
+
    14. PHP script for web server
+
    15. url rewrite rule for web server
 
    16. Create self-signed ssl-certificate
 
    17. Seamless ssl-certificate exchange
 
    18. reseed server domain/url/port exchange
@@ -183,22 +188,22 @@ Thank you!
 
    19. matt's go solution - Run the reseed server
 
    20. matt's go solution - Draft for startup script
 
    21. matt's go solution - reverse-proxy setup
-
    22. matt's go solution - Convert existing java keystore to crt- and pem-file
+
    23. matt's go solution - Convert existing Java keystore to crt- and pem-file

    1. Intro

    -Public reseed servers are necessary to bootstrap into the i2p net. -New installed i2p routers needs one-time a handful RouterInfo's (RI) as jump start. +Public reseed servers are necessary to bootstrap into the I2P net. +New installed I2P routers needs one-time about one hundred RouterInfo's (RI) as jump start.

    -RI contains IP and Port from other i2p-routers and are stored in dat-files in the netDB folder. +RI contains IP and Port from other I2P routers and are stored in dat-files in the netDB folder.

    A random bunch of dat-files from the netDB are zipped, then signed to a su3-file -and finally offered to i2p-routers seeking reseed service. +and finally offered to I2P routers seeking reseed service.

    To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory. @@ -208,7 +213,7 @@ It is essential not to publish all RI from netDB, or all RI to one client. So a cronjob will be setup providing only a part of all available RI.

    -A php script ensures that requests to the public reseed server provides only +A PHP script ensures that requests to the public reseed server provides only one su3-file within 24h for one client IP.

    @@ -219,22 +224,22 @@ one su3-file within 24h for one client IP.

    Requirements for running a public reseed server:

      -
    • well integrated running i2p router @ 24/7 +
    • well integrated running I2P router @ 24/7
    • server with static IPv4 (2 cpu/ 2GB ram is already fine) -
    • unix to run the shell script, cronjobs or matts solution +
    • Unix to run the shell script, cronjobs or matts solution
    • own domain, a third level domain is fine too and may provide you with more anonymity.
    • a self signed ssl-certificate is ok -
    • web-space (HTTPS only) with php5+rewrite-rule -
    • HTTPS only, with TLS 1.2, only with good ciphers +
    • web server (HTTPS only) with PHP5+rewrite-rule works, but can't be protected from botnet? +
    • only HTTPS with TLS 1.2 and only good ciphers
    • enough bandwidth and traffic volume (due to a annoying botnet expect up to 1TB per month)
    • fail2ban to protect you from the botnet

    This How-to is tested with Ubuntu/Debian -The web-space has to be public reachable from all over the world, an eepsite inside i2p can be setup in addition. +The web server has to be public reachable from all over the world, an eepsite inside I2P can be setup in addition. Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server. -The webserver doesn't need to listen at default SSL/TSL port 443 - any other port can be used for obfuscation. +The web server doesn't need to listen at default SSL/TSL port 443 - any other port can be used for obfuscation. @@ -242,12 +247,12 @@ The webserver doesn't need to listen at default SSL/TSL port 443 - any other por

    3. Short overview

      -
    • permanent: run your i2p router +
    • permanent: run your I2P router
    • once: generate a private and public key pair for signing the reseed files -
    • once: setup the php script on the web-space -
    • once: setup a rewrite rule at webserver (*.su3 --> su3.php) -
    • regularly: run the unix shell script to generate up-to-date su3-files -
    • regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web-space +
    • once: setup the PHP script on the web server +
    • once: setup a rewrite rule at web server (*.su3 --> su3.php) +
    • regularly: run the Unix shell script to generate up-to-date su3-files +
    • regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web server
    @@ -284,8 +289,8 @@ The webserver doesn't need to listen at default SSL/TSL port 443 - any other por
  • Details are posted here from zzz: zzz.i2p
  • Who? All owner of a public reseed server.
  • Why? su3 reseed files will be signed with your private key. -
  • This ensures a secure bootstrap for i2p routers. -
  • Corresponding public keys will be included in i2p router package. +
  • This ensures a secure bootstrap for I2P routers. +
  • Corresponding public keys will be included in I2P router package.

    @@ -330,7 +335,7 @@ There is no requirement that it be xxx@mail.i2p, any email is fine, or for that (from zzz.i2p) This describes a mechanism for creating and distributing the RI in new su3 format. It's independent from legacy way of doing (fetching dat-files) and can be used in parallel. -This idea don't need mysql, only some Unix shell tools and a simple web-space with php works fine. +This idea doesn't need mysql, only some Unix shell tools and a simple web server with PHP works fine.

    A requesting client gets ~75 RI packed into one zip, signed and converted to a su3-file. @@ -339,14 +344,14 @@ But don't try to keep track of million client IP's in a database, e.g think of i Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo. n is the unlimited IPv4+IPv6 address space, and m are e.g. 100 pre-calculated su3-files. A client with one IP gets always the same su3-file, until the su3-file is updated or the client has a new IP. -A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in i2p net grow. +A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in I2P net grow.

    Once or twice a week (or daily): pre-calculate ~100 new su3-files, each includes ~75 RI. -The RI are fetched from a well running i2p router's netdb directory. -Transfer the pre-calculate su3-files to your web-space, e.g. by sftp or copy them locally to /var/www/su3/. -In the web-space a php script will match one client IP to one of the 100 su3-files by hash+modulo. -This has the advantage to split su3-generation and publishing in web-space . +The RI are fetched from a well running I2P router's netdb directory. +Transfer the pre-calculate su3-files to your web server, e.g. by sftp or copy them locally to /var/www/su3/. +In the web server a PHP script will match one client IP to one of the 100 su3-files by hash+modulo. +This has the advantage to split su3-generation and publishing in web server .

    Requirements for su3-file generation: @@ -356,16 +361,16 @@ Requirements for su3-file generation:

  • Unix shell: find, awk, cat, ...
  • your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password -Requirements for web-space : +Requirements for web server :
      -
    • php5 -
    • rewrite rule (*.su3 --> php) +
    • PHP5 +
    • rewrite rule (*.su3 --> PHP)
    The following solution for a public reseed server consists of three parts:
      -
    • unix shell script for cronjob -
    • php script +
    • Unix shell script for cronjob +
    • PHP script
    • url rewrite rule
    They are described on the following chapters in more detail. @@ -373,11 +378,11 @@ They are described on the following chapters in more detail. -

    7. unix shell script for cronjob

    +

    7. Unix shell script for cronjob

    This script pre-calculates n su3-files. -Requirements: unix shell, java, i2p, zip-tool, your private reseed signing key +Requirements: Unix shell, Java, I2P, zip-tool, your private reseed signing key Main Steps: 

     # CONFIG
@@ -400,9 +405,9 @@ The number of generated su3-files is random too, it depends on your netdb size a
 
 
    
 Only 66% of all RI from your netdb are used, netdb may be not older than 10h.
-It is possible to separate cronjob script from php script:
-Run the cronjob script on your i2p machine and then transfer the final su3-files via (s)ftp/ssh
-to your webserver from time to time. su3 file-size in this setup is between 50 and 100 KB per file.
+It is possible to separate cronjob script from PHP script:
+Run the cronjob script on your I2P machine and then transfer the final su3-files via (s)ftp/ssh
+to your web server from time to time. su3 file-size in this setup is between 50 and 100 KB per file.
 
 
 
@@ -423,11 +428,11 @@ Recommendation is to update the su3-files once every 1..10 days.
 
 
 
-
    9. php script for webserver
    
+
    9. PHP script for web server
    
 
 
    
 The su3.php script maps always one client IP to one pre-calculated su3-file.
-Requirements: a webserver with php5
+Requirements: a web server with PHP5
 Main Steps:
 
     # CONFIG
@@ -453,19 +458,19 @@ Clients in the same "subnet" gets the same su3-file
 A clients gets only different su3-file package in following circumstances:
 
      
 
    • when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address)
-
    • at 00:00 every date (date function in php)
-
    • when the unix cronjob updates the su3 files
+
    • at 00:00 every date (date function in PHP)
+
    • when the Unix cronjob updates the su3 files
 
    
 
 
 
 
 
-
    10. url rewrite rule for webserver
    
+
    10. url rewrite rule for web server
    
 
 
    
-It is mandatory that clients does not have direct access to the su3-files at the webserver.
-Please activate a rewrite rule for su3-files in your webserver pointing to the su3.php file:
+It is mandatory that clients does not have direct access to the su3-files at the web server.
+Please activate a rewrite rule for su3-files in your web server pointing to the su3.php file:
 
     	*.su3 --> su3.php?file=$1
 
    
@@ -490,8 +495,8 @@ We want only HTTPS accessible reseed server.
 Sorted by best solution:
 
      
 
    • please deactivate plain HTTP, or
-
    • use a redirect rule in your webserver, or
-
    • implement the redirect to HTTPS in the php-code
+
    • use a redirect rule in your web server, or
+
    • implement the redirect to HTTPS in the PHP code
 
    
 
 
@@ -523,6 +528,15 @@ Remarks:
 
  • Please fill out all fields, don't use blanks
 
  • rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu
 
  • use rsa, not ecdsa (ecdsa will break currently RetHat users)
+
  • Optional:
+Instead of RSA key and signature use a EC 384 key and signature, example:
+
     
+f=your.server.com
+openssl ecparam -name secp384r1 -genkey -out $f.key
+openssl req -new -x509 -key $f.key -out ${f}.crt -days 2000 -sha512
+cat $f.key $f.crt > $f.pem
+
     
+This results in a EC 384 bit key with SHA512withECDSA signature.
 
  • days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years))
 
  • sha256 - important, without this option openssl currently uses weak sha1 by default
 
  • Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup.
@@ -538,8 +552,8 @@ and save the new file as your.server.com.crt file
 
 
 
    
-Send this to us - the .crt file with the public key section will we included in every i2p router.
-The .pem file with your private key is only for you and your webserver.
+Send this to us - the .crt file with the public key section will we included in every I2P router.
+The .pem file with your private key is only for you and your web server.
 
 
 
@@ -548,7 +562,7 @@ The .pem file with your private key is only for you and your webserver.
 
 
    
 The update/exchange of an already existing self-signed certificates has to be correct timed
-on server *and* client side. Considering thousands of clients (many with older i2p version) the exchange
+on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange
 will not be seamless possible and will have very bad impact on many clients: reseed won't work for them.
 
 
    
@@ -578,7 +592,7 @@ To make the exchange as smooth as possible for many clients please follow these
 
 
      
 
    1. Setup an additional reseed instance at the new domain/url/port
-
    2. we include the new url into i2p source NOW and delete the old url NOW
+
    3. we include the new url into I2P source NOW and delete the old url NOW
 
    4. both of your reseed instances have to run some time in parallel
 
    5. WAIT some month, e.g. 3-4 i2p-releases
 
    6. new url is now hopefully present on many clients
@@ -587,7 +601,7 @@ To make the exchange as smooth as possible for many clients please follow these
 
 
 
-
      14. Testings
      
+
      14. Tests
      
 
 
      
 Some simple pre-test: test the website and fetch
@@ -595,8 +609,9 @@ Some simple pre-test: test the website and fetch
 	wget --user-agent="Wget/1.11.4" -O /tmp/test.su3 --no-check-certificate https://your-server.com:PORT/i2pseeds.su3
 
    • 
 Replace "PORT" with default 443 or your chosen server setting.
-Inspect the fetched file:
+Inspect the fetched file.:
 Some simple pre-test: test the website and fetch
+
     	zipinfo -z /tmp/test.su3
 
    
 
@@ -609,14 +624,14 @@ Everything ok:
 
      
 
    • ssl-certificate chain valid?
 
    • The su3-files can be downloaded?
-
    • contains >50 dat-files?
+
    • contains > 50 dat-files?
 
    • and is always the same for one client-IP?
 
    • other client-IP's gets another file?
 
    • Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ?
 
    
 
 
    
-Do a real reseed test on *another* i2p router machine:
+Do a real reseed test on *another* I2P router machine:
 
      
 
    • include manually new ssl-certificate into i2p installation:	~/i2p/certificates/ssl/
 
    • include manually new public reseed key into i2p installation:	~/i2p/certificates/reseed/
@@ -624,7 +639,7 @@ Do a real reseed test on *another* i2p router machine:
 
    • add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3"
 
    • Save and Shutdown router.
 
    • clear netdb: empty folder ./i2p/netDb.
-
    • Restart i2p and watch the i2p router log:
+
    • Restart I2P and watch the I2P router log:
 
       2014/10/13 23:01:02 | Reseed start
 2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
@@ -844,7 +859,7 @@ The changes for an exiting reseed server with the previous setup are simple:
 
        
 
      • use the latest su3.php from above (minimal version 5, only minor changes, no change of logic).
 
      • add the new reseed.php to your /var/www folder, next to to su3.php
-
      • install php5-gd (restart of php processes may be necessary)
+
      • install php5-gd (restart of PHP processes may be necessary)
 
      • get Securimage php-code from https://www.phpcaptcha.org/
 
      
 
@@ -852,7 +867,7 @@ The changes for an exiting reseed server with the previous setup are simple:
 Quote from https://www.phpcaptcha.org  (2015-03):
 "Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect
 forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots.
-It can run on most any webserver as long as you have PHP installed, and GD support within PHP.
+It can run on most any web server as long as you have PHP installed, and GD support within PHP.
 Securimage does everything from generating the CAPTCHA images to validating the typed code."
 
 
      
@@ -918,7 +933,7 @@ a reseed server which merges the following functions into one binary:
 
    • create su3-files
 
    • create su3 signer certificate+key
 
    • create ssl-certificate+key
-
    • replaces the http-server and the php code (or run next to them in parallel)
+
    • replaces the http-server and the PHP code (or run next to them in parallel)
 
    
 
 
    
@@ -1002,7 +1017,7 @@ $ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOM
 
  • replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose
 
  • new TLS certificate+key will be created (if they do not exist)
 
  • new signing certificate+key will be created (if they do not exist)
-
  • netdb=... should point to the netdb folder of your running i2p with the routerinfos
+
  • netdb=... should point to the netdb folder of your running I2P with the routerinfos
 
  • to use another port append "--port=443" to the command, default is port 8443
 
 
@@ -1022,7 +1037,7 @@ So you can now test to reach the server at port 8443, see a previous chapter abo
 Some remarks:
 
      
 
    • don't run the server daemon as root
-
    • every port between 1024 and 49151 is fine for i2p.
+
    • every port between 1024 and 49151 is fine for I2P.
 
    • if you want to use the privileged (https-default) port 443, create a port redirect, e.g.
     iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-port 8443
 
    • redirect the output from the go solution to a logfile, format is default apache-style combined logs
@@ -1036,38 +1051,182 @@ in order for your reseed server to be included in the standard I2P package.
 
 
 
-
      22. matt's go solution - Draft for startup script
      
+
      22. matt's go solution - Draft for startup script "seedserver"
      
 
 
      
-The reseed server should be started automatically, so you need a init.d or some sort of startscript.
+The reseed server should be started automatically, so you need a init.d or some sort of
+startscript, here named as "seedserver".
 This is only a very first draft for a simple startscript (it could be done better :-))
-The startscript can be placed in your personal crontab: @reboot   sleep 20 && /path_to/startscript
-
+
      
+Login as I2P user:
+
        
+
      • place the shell-script "seedserver" in the /home/i2p/bin folder (next to i2p-tools)
+
      • make it executable: chmod u+x /home/i2p/bin/seedserver
+
      
+Update the header "# Your settings" with your individual settings.
 
 
      
-Two logfiles are specified:
+Now you can use the shell-script:
+
      +seedserver start
+
      
+
      
+And then (give it some seconds) take a look at the status:
+
      +seedserver status
+seedserver showlog
+
      
+
+
      
+Some short explanation about seedserver:
 
        
-
      • reseed.log - apache-style combined logs
-
      • reseed.error	- any error messages
+
      • runs i2p-tools in the background
+
      • creates logfiles
+
      • take care of all settings
 
      
 
 
      
-startscript:
+If this is working fine, you can put the script in your personal crontab, to run it by auto-start
+and to do logrotes simply by restarting it regularly once a week to avoid too big logfiles.
+If you already reboot your server regularly, you can skip of course the "restart" command line.
+
+
      
+Login as I2P user, edit your crontab:
+
      +crontab -e
+
      
+
      
+and add these 3 lines at the end:
+
      +@reboot /home/i2p/bin/seedserver startdelayed
+04 14 * * 2 /home/i2p/bin/seedserver restart
+#end
+
      
+
+
      
+Save and close the editor. It would be good to check if this is properly working when you reboot your machine.
+
+
      
+"seedserver" shell script:
 
 
       ######################################################################################################
 #!/bin/sh
 
-export HOME=/home/i2puser
-export GOPATH=$HOME/go
-export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
+# Your settings
+toolpath=/home/i2p/bin
+tlsHost=myserver.com
+signer=myemail@mail.i2p
+netdb="/home/i2p/.i2p/netDb"
 
-cd $GOPATH
-logfile=$HOME/go/reseed.log
-errfile=$HOME/go/reseed.error
 
-i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb >>$logfile 2>>$errfile &
-disown -h
+tool=i2p-tools
+logpath="$toolpath/${tool}.log"
+logfile="$logpath/reseed.log"
+errfile="$logpath/reseed.error"
+
+cd "$toolpath"
+mkdir --parents "$logpath"
+
+
+do_status() {
+/bin/sleep 1
+if [ -n "$(pgrep -x "$tool")" ]; then
+echo "$tool running, pid $(pgrep "$tool")"
+else
+echo "$tool not running."
+fi;
+}
+
+do_start() {
+if [ -z "$(pgrep -x "$tool")" ]; then
+do_logrotate
+nohup "$toolpath/$tool" reseed -tlsHost="$tlsHost" --signer="$signer" --netdb="$netdb" > "$logfile" 2> "$errfile" &
+fi;
+do_status
+}
+
+do_stop() {
+if [ -n "$(pgrep -x "$tool")" ]; then
+pkill "$tool"
+fi;
+do_status
+}
+
+do_startdelayed() {
+echo "waiting 20s..."
+/bin/sleep 20
+do_start
+}
+
+do_restart() {
+do_status
+do_stop
+do_start
+}
+
+do_logrotate() {
+do_status
+if [ -z "$(pgrep -x "$tool")" ]; then
+mv --force "${logfile}.6" "${logfile}.7" 2>/dev/null
+mv --force "${logfile}.5" "${logfile}.6" 2>/dev/null
+mv --force "${logfile}.4" "${logfile}.5" 2>/dev/null
+mv --force "${logfile}.3" "${logfile}.4" 2>/dev/null
+mv --force "${logfile}.2" "${logfile}.3" 2>/dev/null
+mv --force "${logfile}.1" "${logfile}.2" 2>/dev/null
+mv --force "${logfile}" "${logfile}.1" 2>/dev/null
+mv --force "${errfile}.6" "${errfile}.7" 2>/dev/null
+mv --force "${errfile}.5" "${errfile}.6" 2>/dev/null
+mv --force "${errfile}.4" "${errfile}.5" 2>/dev/null
+mv --force "${errfile}.3" "${errfile}.4" 2>/dev/null
+mv --force "${errfile}.2" "${errfile}.3" 2>/dev/null
+mv --force "${errfile}.1" "${errfile}.2" 2>/dev/null
+mv --force "${errfile}" "${errfile}.1" 2>/dev/null
+echo "log-rotate done."
+else
+echo "log-rotate not possible."
+fi;
+}
+
+do_showlog() {
+echo "-------------------------------------------------------------------------------"
+tail "$errfile"
+echo "-------------------------------------------------------------------------------"
+tail "$logfile"
+echo "-------------------------------------------------------------------------------"
+}
+
+
+do_usage() {
+echo "Usage: {start|stop|status|restart|logrotate|startdelayed|showlog}"
+}
+
+case "$1" in
+start)
+do_start
+;;
+stop)
+do_stop
+;;
+status)
+do_status
+;;
+restart)
+do_restart
+;;
+startdelayed)
+do_startdelayed
+;;
+logrotate)
+do_logrotate
+;;
+showlog)
+do_showlog
+;;
+*)
+do_usage
+;;
+esac
 
 exit 0
 ######################################################################################################
@@ -1131,23 +1290,23 @@ and for X-Forwarded-For:
 
 
 
-
      24. matt's go solution - Convert existing java keystore to crt- and pem-file
      
+
      24. matt's go solution - Convert existing Java keystore to crt- and pem-file
      
 
 
      
-This describes how to convert your existing java keystore with your su3 signing key to a plain crt- and pem-file.
-This is only needed, when you already have a java keystore and want to use matt's go solution.
+This describes how to convert your existing Java keystore with your su3 signing key to a plain crt- and pem-file.
+This is only needed, when you already have a Java keystore and want to use matt's go solution.
 If you create new keys+certs with matt's solution you can skip this chapter!
 
 
      
 Requirements:
 
        
-
      • java keytool
+
      • Java keytool
 
      • openssl
 
      • and of course your secret password for the keystore
 
      
 
 
      
-Keep in mind: the java keystore has two passwords:
+Keep in mind: the Java keystore has two passwords:
 
        
 
      • the secret key password you have entered while creating your keystore the first time (SU3File keygen ...)
 
      • and a "storage" password, which is most probably default "changeit".

From ea57d34a41d38c14e14f2e139ac45776bdad28fa Mon Sep 17 00:00:00 2001
From: echelon2 
Date: Wed, 30 Dec 2015 10:23:49 +0000
Subject: [PATCH 055/114] small typo

---
 i2p2www/pages/site/get-involved/guides/reseed.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html
index 9de92af4..d838ffe9 100644
--- a/i2p2www/pages/site/get-involved/guides/reseed.html
+++ b/i2p2www/pages/site/get-involved/guides/reseed.html
@@ -18,7 +18,7 @@ At its simplest, a reseed server consists of a Java I2P router, an HTTPS web ser
 and some scripts that periodically gather router infos from the router,
 bundle and sign them into a custom file format, and deliver these files over HTTPS.
 In practice, it's a bit more complex, and a reseed operator must be fairly competent and attentive.
-A reseed server is not appropriate for a residential internat connection. The complexities include:
+A reseed server is not appropriate for a residential internet connection. The complexities include:
 {%- endtrans %}
        
 
 
          

From 0d13f05d17db6dbe48f9637fb219132d80708cc2 Mon Sep 17 00:00:00 2001
From: kytv 
Date: Thu, 31 Dec 2015 13:04:03 +0000
Subject: [PATCH 056/114] logs for 30-DEC meeting

---
 i2p2www/meetings/logs/241.log | 256 ++++++++++++++++++++++++++++++++++
 i2p2www/meetings/logs/241.rst |  18 +++
 2 files changed, 274 insertions(+)
 create mode 100644 i2p2www/meetings/logs/241.log
 create mode 100644 i2p2www/meetings/logs/241.rst

diff --git a/i2p2www/meetings/logs/241.log b/i2p2www/meetings/logs/241.log
new file mode 100644
index 00000000..8110d0f8
--- /dev/null
+++ b/i2p2www/meetings/logs/241.log
@@ -0,0 +1,256 @@
+09:49:14   0) Hi
+09:49:14   1) Meeting structure and goals
+09:49:14   2) PR
+09:49:14   3) Project Management
+09:49:14   0) Hi
+09:49:16   Hi
+09:49:30   1) Meeting structure and goals
+09:49:30   First of all I apologize for the horrendous time for this meeting for our North American folks.
+09:49:30   This will be a little different from our usual meeting structure because it's mostly in-person here at CCC.
+09:49:31   We will attempt to relay the highlights to IRC.
+09:49:33   We will also be taking notes here.
+09:49:35   Now let me give a preamble for this meeting.
+09:49:49   As you all should know, Sadie was a huge part of the organization and success of I2PCon in Toronto.
+09:49:49   We all saw her talent and enthusiasm in Toronto, and obviously she wants to do more for I2P going forward.
+09:49:49   As we got to work with her before and during the Con, we learned that she has extensive Project Management and PR experience,
+09:49:49   both with Tor and out in the real world.
+09:49:49   What I asked her to do after the Con was to get to know our project better, to understand our current structure and processes,
+09:49:52   and to come back with recommendations on what we could do better and how she could help us.
+09:50:04   Since then, she's had several long conference calls with tuna, me, str4d, psi, and others,
+09:50:04   and reviewed our website, trac, and current processes.
+09:50:04   Also, psi has named her Assistant PR Director and she is tweeting on the @GetI2P account and helping to get the word out about I2P.
+09:50:06   She is now ready to give us some recommendations.
+09:50:06   While my original question to her was "how can you help us?", the answer coming back is
+09:50:06   more like "here's the things we need to fix so I can effectively help",
+09:50:08   followed by the actual things she could do for us, or more precisely how we can all work together more effectively.
+09:50:19   What I'd like to do today is to hear her recommendations and discuss them each briefly.
+09:50:19   Many of these topics tend to spark long discussion and I'd like to contain that so we aren't here all day.
+09:50:19   For each recommendation, I'd like to get a commitment from one of you to follow up.
+09:50:19   If the recommendation is uncontroversial and we have consensus, that commitment would be to implement it.
+09:50:20   If it needs further research or we don't agree, that commitment would be to review our options and
+09:50:21   come up with a plan, or a counter proposal, or a list of options to be discussed at a future meeting.
+09:50:23   These commitments and due dates will be noted and tracked.
+09:50:25   I don't want to get bogged down on any one thing so I'll be looking for volunteers to follow up most things.
+09:50:42   I want to emphasize that I asked Sadie to do this and give us her opinion based on her previous experience.
+09:50:42   We may not agree but we should listen and carefully consider her recommendations.
+09:50:42   I2P is its own little snowflake and not everything may be appropriate for us,
+09:50:42   but she's gotten to know us pretty well this year, so let's hear what she's got.
+09:50:43   We will of course be able to take suggestions from others but I have a feeling that Sadie's got a lot of things covered already.
+09:51:24   We're going to first talk about PR and then Project Management.
+09:51:24   Both are very large topics and there will be overlap. But let's try to keep them as separated as we can.
+09:51:54   *** end of paste for topic 1), we will start in with 2) in a few minutes. thanks ***
+09:58:39   str4d: heya we should have a talk about the DH stuff we're using
+09:59:30   hottuna, you referring to the NTCP and SSU handshakes?
+09:59:55   i guess wherever DH is used
+10:00:39   ok. lets talk about it after the meeting
+10:00:47   Sure
+10:00:57   According to http://trac.i2p2.i2p/wiki/Crypto/CurrentSpecs it's just NTCP and SSU
+10:01:21   zzz will be reading the long note above to us now
+10:01:48   (I still need to update that page ahead of my talk)
+10:04:10   i think i'm here
+10:06:33   psi: yes, zzz posted a long message just before you joined. talking IRL right now
+10:07:57   So what we're looking to do is to get commitments from people to fix a bunch of different topics
+10:08:25   Some of the stuff we're going to cover will be controversial and some not
+10:08:47   the non-controversial topics we're hoping to just assign a to a person and have that handled
+10:08:56   Onto Sadie and PR
+10:09:16   gravy and sadie have been writing blogpost
+10:09:29   and are looking for more content
+10:10:21   a lot of content is lost in the commit messages
+10:10:38   where the author of the commit does not really record the importance of the commit
+10:11:24   Rather than scanning commit messages, the best/easiest place to look is history.txt
+10:11:30   ideally we would like to publish a blog post at least every 2 months to keep some sense of momentum is kept
+10:12:08   That still doesn't give an indication of importance, but is contextually easier to handle and sifts out the commit chaff that doesn't make it into history.txt
+10:13:04   str4d: the point is that there is so many cool things happening, and no way to find out without following i2p closely. it should be easier for people to see the cool stuff
+10:13:47   Perhaps what might help (this would be rather radical) could be to restructure history.txt to organize items by importance (major/minor/bugfix), more like a changelog (or have a parallel changelog file)
+10:14:13   since as-is, the history file is really just an easier-to-parse commit log
+10:14:30   That said, it *is* convenient, so maybe parallel info would be better (if harder to maintain)
+10:14:38  * str4d stops getting bogged down in specifics
+10:14:41   :P
+10:14:59   lazygravy could act as an editor and sort of delegate the responsibility of writing content when that is appropriate
+10:15:14   Certainly making it easier to know what is going on is a plus, and I think some of the higher-level organization topics will help this
+10:15:33   (ie. a blog post writer can look there for the high-level overview instead of the commit log)
+10:15:56   sounds rather similar to pair programming
+10:16:10   next topic within PR
+10:16:29   regarding having a reseed campaign and attracting new developers
+10:16:46   (or more like married couple programming, the programmer and the programmer's wife)
+10:17:11   str4d: i.e. WTF encrypted lease sets are, or a cool highlight of kytv's debian repo
+10:17:15   we would like to involve torontocrypto to attract more reseed host s
+10:17:23   s/i.e./e.g./
+10:17:24   lazygravy meant: str4d: e.g. WTF encrypted lease sets are, or a cool highlight of kytv's debian repo
+10:18:25   We would like to generate a content package containing all info you would need to set up a reseed host should be available in one place
+10:19:14   we need to articulate why reseeds are needed and important
+10:19:18   Mmm
+10:19:42   It could even be made as simple as "sudo apt-get i2p-reseed"
+10:20:22   str4d++
+10:20:23   I was thinking of making docker images so it can be completely plug-n-play:ed
+10:20:47   the go reseed was excessively easy to set up and use
+10:20:56   hottuna/I volunteered to write a few paragraphs about why reseeds are needed and what they do
+10:21:07   kytv: that would be amazing
+10:21:23   kytv++
+10:21:35   Drop-and-go is the ideal
+10:22:00   Kinda like what was mentioned in one of the Tor talks yesterday, about how people could in future get a LetsEncrypt cert that comes with a free .onion
+10:22:16   (ie. the letsencrypt script sets up the Tor HS for the user)
+10:22:38   mdrollete's i2p-tools is available as a docker image, so maybe we (=I) could just polish up my I2P docker image (not yet advertised) so one could do it all by copy'n'pasting one command line and reseeding would "just work"
+10:22:41   about developed onboarding, making the source code more accessible
+10:22:42   (that in itself would be super neat for I2P, but slightly different from what we need here)
+10:22:55   kytv: docker for sure
+10:23:01   str4d: could I convince you to add some links to the source code from geti2p.net?
+10:23:04   If reseeds are an appliance, it also makes it much easier to keep honest reseeds in sync
+10:23:17   hottuna, where?
+10:23:18   thought: we should get rid of the note from 0.7.6 on the download page
+10:23:33   (I'm more of an lxc guy but I'm learning docker so whatevs ☺)
+10:23:45   ja
+10:23:50   kytv: docker seems "so hot" right now, so it might be best
+10:23:54   wherever it makes sense
+10:24:08   I believe there is at least one link to kytv's ViewMTN, but that's inside I2P
+10:24:11   but the idea is to make it easier to get a quick look at the soruce code
+10:24:13   Move all docs for ancient stuff to /attic or smth related
+10:24:19   to attract developers
+10:24:33   str4d outside i2p and ideally from geti2p.net is what we would want
+10:24:36   I could add links to the new devs page to the Github page, but they would need to be clearly marked as read-only
+10:24:50   if you really want to attract devs we should make the github alive more
+10:24:52   yeah.
+10:25:57   Is the new dev page where you want the links?
+10:25:57   that sounds like a simple straight forward step to take
+10:25:57   just add a read-only link to github
+10:25:57   hottuna, which? Links, or github alive more?
+10:25:57   would be an improvement
+10:25:57   ahk
+10:26:05   str4d: can I write your name next to that?
+10:26:24   that item that is
+10:26:38   Sure. I assume all of these will get issues created on Trac
+10:26:51   not sure if they will.
+10:26:57   will ask zzz
+10:27:09   Well yeah, probably not worth it for the smaller tasks
+10:27:20   As long as I get the list sometime :P
+10:27:26   ok
+10:27:36   i think zzz will do a zzz.i2p writeup
+10:28:22   it'll almost certainly go to zzz.i2p but perhaps also as tickets on Trac
+10:28:41   k
+10:28:50  * str4d pulls up todo list to start adding items
+10:32:43   we're talking about which usecasdes we should promote i2p for
+10:33:13   and the consesus seems to be  that we should promote usecases which we are good at. like bote
+10:33:20   Mmm
+10:33:29   We definitely need to push the peer-to-peer aspect
+10:33:36   like torrents to potintiall
+10:33:38   y
+10:33:57   we would like to highlight these good uses on the main page
+10:34:12   *what we would like to highlight
+10:34:20   That's something I2P should have a fundamental advantage with, due to the packet-switched nature and tunnel-level symmetry
+10:34:33   yes. and there are other things we are good at
+10:34:39   And particularly apps that themselves inherently encourage contribution
+10:34:41   and those things we should promote
+10:35:05   and in the meantime we can keep on working on the things that we are not quite as good at
+10:35:09   (because I2P's need for contribution can then piggyback on the app's)
+10:35:43   lazygravy, str4d, cacapo: could you work through the 3 best usecases for i2p
+10:36:01   so that we then can present them properly on the frontpage
+10:36:18   Sure
+10:37:03   yepp
+10:37:08   when can you guys come back with something (recommendations or webstie changes)?
+10:37:43   is a deadline for end of january ok?
+10:37:55   ok
+10:38:01   realting to PR: i2p.net becomes available soon
+10:38:03   Fine with me
+10:39:04   16.4.2016 it is for i2p,net
+10:39:11   I can say right now that if we are meaning "things that work well right now", you're really looking only at high-latency email (bote) and torrents. Soon we can add distributed datastorage too (once Tahoe gets native I2P client support)
+10:39:24  * str4d is looking forward to i2p.net being recovered
+10:39:33   tahoe will only be useable with parallel up/download
+10:40:08   I think it would be ideal to dovetail it with my proposal for dev services on i2p.i2p, have them parallel available in- and out-of-net
+10:40:12   cacapo mentions i2p does not communicate a narrative about the project very well. or at all.
+10:40:29   str4d: tahoe has it's own UI problems... :/ (tho I adore it)
+10:40:29   unlike to which has a lot of history and contextual history to it
+10:41:03   hottuna, what narrative does he mean?
+10:41:09   relating to jake/snowden&/etc
+10:41:42   ah, narrative relating I2P history to world context?
+10:41:43   comraden1: volunteers to do a writeup of the history of i2p
+10:41:52   (like the Tor HS talk did?)
+10:42:05   history: zzz talk on i2pcon, my talk on 32c3
+10:42:06   (didnt see that)
+10:42:33   also my talk at I2PCon had a bit
+10:42:37   zzz, comraden1, lazygravy volunteered to do the actual writeup
+10:42:41   psi: around?
+10:42:53   yes
+10:42:57   str4d: and so did Lance James' bit
+10:43:34   lazygravy, Tahoe UX should improve greatly once magic folders is released. UI-wise, still has work to do, but not as much as us :P
+10:43:52   str4d, sadie, could the both of you help eachother out to do promo for the RWC talk?
+10:44:03   Öast call for PR related topics
+10:44:06   Lest*
+10:44:08   last*
+10:44:49   alright, i'll take that as silence
+10:44:50   hottuna, yep, I'll keep in touch with Sadie
+10:44:56  * str4d still has to prepare that talk :/
+10:45:04   Onto the next topic. PROJECT MANAGEMENT
+10:45:34   str4d: also "history of how i2p started". I'm thinking of navy researching onion routing -> second generation onion router -> tor
+10:46:40   comraden1, mmm, you'll probably find a lot of that in the early I2P meeting logs on the website
+10:47:15   If you do go rooting around in there, feel free to write quick summaries of the meetings that I can add to them :P
+10:48:11   str4d: zzz mentioned that he has a lot of it in his head and wanted to write a rough draft. I'm going to edit and make sure it is perfect before we release it
+10:48:45   +1
+10:49:19   I remember speaking about it with zzz ages ago; if he has logs of that, it might be helpful
+10:49:22   we're talking about what the actual goals of the project are
+10:49:54   and that they are important to have written down somewhere in order to be able to do meaningful project management
+10:50:29   Would make for a good about page
+10:51:16   I've wanted to merge the various intro pages, but we could actually leverage them separately
+10:51:36   Turn https://geti2p.net/en/about/intro into a brief overview of I2P, both the network and the project
+10:51:38   Title: Intro - I2P (at geti2p.net)
+10:51:59   Then make https://geti2p.net/en/docs/how/intro the *actual* "how does I2P work" page
+10:52:00   Title: A Gentle Introduction to How I2P Works - I2P (at geti2p.net)
+10:52:10   Kinda sorta what they appear to be now, but properly split
+10:53:12   hottuna: Where can I find the blogposts?
+10:53:22   hottuna: I can only see one (http://i2p-projekt.i2p/en/blog/post/2015/11/15/Community-Outreach)
+10:53:25   Title: Community Outreach - Blog - I2P (at i2p-projekt.i2p)
+10:54:38   dg: they don't exist aside from that
+10:54:55   and that was mostly a POC IMO. Next one should be published on 10Jan2016 on CCC
+10:58:32   we're talking about whether we want to be managed
+10:58:46   dg, str4d, psi: do you have any thoughts about having your work managed?
+10:59:11   by who and how much management?
+10:59:17   by sadie
+10:59:26   open to it
+10:59:42   and having it be relaxed as in deadlines. but not enforced deadlines
+10:59:46   things are done when they are done
+11:00:11   but mentally attaching a deadline to them might be a helpful tool
+11:00:11   done when they're done but a bit of pushing/motivation
+11:00:40   no thoughts until i eat breakfast
+11:00:47   or at the very least knowing that someone else knows that a given task  is on your pile
+11:01:15   re project management: we'd like to get weekly/bi-weekly meetings up and runnning again
+11:01:25   zzz has the goal of starting them up in february agin
+11:01:27   again*
+11:01:36   and then gradually handing them off to sadie
+11:01:48   for that to happen sadie needs got on irc
+11:01:56   I'm good for it. I do tend to work better when I have someone(s) to bounce ideas off
+11:03:23   zzz just committed to having a single roadmap written up by the end of february
+11:03:23   splendid.
+11:03:23   the consensus seems to be that being managed lightly is probably a good thing.
+11:03:23   but anything heavy-handed would just turn this into work
+11:03:23   Sounds good. We can always adjust the level later once we have some experience with it.
+11:03:23  * dg nods
+11:03:23   *roadmap will be for end of jan, not feb
+11:03:23   str4d: agreed
+11:04:35   FYI zzz, sadie and I will be meeting up at the beginning of March, would be good to keep that in mind re: things we can work on/discuss then.
+11:05:52   re: trac tickets, sadie is volunteering to keep an eye on it and relay tickets to the right individual
+11:06:05   Being able to observe our mechanics like trac/zzz.i2p/irc is important for Sadie to fully understand how we work anyway
+11:06:16   Has she been able to do that w/o IRC access?
+11:07:04   str4d: would you bi willing to help sadie out in that endeavour?
+11:07:40   I've had on my todo list for a while a weekly "look over new tickets" item, that I keep postponing because too much on
+11:08:06   But from next year, I'll endeavour to help sadie with that :)
+11:08:49   You may have noticed there's an "open" status now for tickets. I added that so we can differentiate between new tickets and ones we've seen but haven't had an opinion on necessarily
+11:08:53   Last call for PROJECT MANAGEMENT topics
+11:09:10   hottuna: see above
+11:09:25   My goal would be to have as few "new" tickets as possible, ie. moving them either to a relevant person/status, or "open" to at least acknowledge them as a valid ticket.
+11:09:36   Last call for OTHER topics
+11:09:48   dg: getting sadie on trac is key. and a requirement
+11:10:00   I mean on IRC
+11:10:17   okay
+11:10:23   I've had an IRC bouncer account for her for a while now
+11:10:42   str4d: could we ask you to write up few items about what you learned about vulnerability response the the conf?
+11:10:48   All she needs is help getting her side connected, and she can then keep logs etc. without needing to stay connected all the time
+11:11:40   hottuna, you mean from talking to k8em0 at Kiwicon?
+11:11:47   mhm
+11:11:47   Also help with browser config/privoxy?
+11:12:13   I didn't learn a lot more than I already kinda knew, other than hearing in advance about the bug bounty program that Tor just announced
+11:12:26   we're proposing that we defer the VRP discussion to january
+11:12:36   str4d: would making a tiny writeup make sense?
+11:12:40   k8em0 did say she was very impressed with our VRP ticket
+11:12:45   like a zzz.i2p post?
+11:12:55   or was it all kind of useless?
+11:13:15   Not useless, more confirming that our VRP ticket is on the right track
+11:13:31  * zzz ******BAFFFFS***** the meeting closed, thanks everybody
diff --git a/i2p2www/meetings/logs/241.rst b/i2p2www/meetings/logs/241.rst
new file mode 100644
index 00000000..84f47503
--- /dev/null
+++ b/i2p2www/meetings/logs/241.rst
@@ -0,0 +1,18 @@
+I2P dev meeting, December 30, 2015 @ 10:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+cacapo,
+comraden1,
+dg,
+eche\|on,
+hottuna,
+kytv,
+lazygravy,
+psi,
+str4d,
+zzz,

From d71728232ddfb9bf14944e696f8a4c32f37add7f Mon Sep 17 00:00:00 2001
From: lazygravy 
Date: Fri, 1 Jan 2016 18:15:39 +0000
Subject: [PATCH 057/114] Fixing 404 on "Release Notes" link.

Using https on external links where possible.
---
 i2p2www/pages/downloads/list.html | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html
index 811aca08..d36baa90 100644
--- a/i2p2www/pages/downloads/list.html
+++ b/i2p2www/pages/downloads/list.html
@@ -19,12 +19,12 @@
 
 {% block content %}
 
          {{ _('Dependency') }}
          
-
          {% trans java='http://java.com/download/',
+
          {% trans java='https://java.com/download/',
 openjdk='http://openjdk.java.net/install/',
 icedtea='http://icedtea.classpath.org/wiki/Main_Page',
 arm8='http://www.oracle.com/technetwork/java/javase/downloads/jdk8-arm-downloads-2187472.html',
 ibmsdk7='http://www.ibm.com/developerworks/java/jdk/linux/download.html',
-detectjre='http://java.com/en/download/installed.jsp?detect=jre&try=1' %}
+detectjre='https://java.com/en/download/installed.jsp?detect=jre&try=1' %}
 Java Runtime 1.6 or higher.
 (Oracle,
 OpenJDK, or
@@ -39,9 +39,10 @@ or type java -version at your command prompt.
 
 
 
+{% trans release_notes=site_url('blog/category/release') -%}
 
          {{ _('Release Notes') }}
          
 
+{% endtrans %}
          
 
 
 

From 927ccbe9538fd012464f425b0be5cc1d398cddf5 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sat, 2 Jan 2016 17:05:35 +0000
Subject: [PATCH 058/114] bring roadmap up to date

---
 i2p2www/pages/site/docs/index.html           |   8 +-
 i2p2www/pages/site/get-involved/roadmap.html | 191 ++++++++++++++++---
 i2p2www/pages/site/get-involved/todo.html    |   5 +
 3 files changed, 177 insertions(+), 27 deletions(-)

diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html
index e59e8756..4e534e8e 100644
--- a/i2p2www/pages/site/docs/index.html
+++ b/i2p2www/pages/site/docs/index.html
@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %}
-{% block accuratefor %}0.9.23{% endblock %}
+{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.24{% endblock %}
 {% block content %}
 
          {% trans -%}
 Following is an index to the technical documentation for I2P.
@@ -243,9 +243,7 @@ Traditionally used only by Java applications and higher-level APIs.
 
        • 
 {{ _('Source translation at Transifex') }}
 
        • 
-{{ _('Roadmap wiki') }}
-
        • 
-{{ _('Old roadmap') }} ({{ _('not current') }})
+{{ _('Roadmap') }}
 
        • 
 {{ _('To Do List') }} ({{ _('not current') }})
 
        • 
diff --git a/i2p2www/pages/site/get-involved/roadmap.html b/i2p2www/pages/site/get-involved/roadmap.html
index 55b4b758..6dea0ffa 100644
--- a/i2p2www/pages/site/get-involved/roadmap.html
+++ b/i2p2www/pages/site/get-involved/roadmap.html
@@ -1,37 +1,184 @@
 {% extends "global/layout.html" %}
 {% block title %}{{ _('Roadmap') }}{% endblock %}
+{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %}
 {% block content %}
 
-
          0.9
          
+
          
+This is the official project roadmap for the desktop and Android Java I2P releases only.
+
          
+For details and discussion on specific items, search on trac or zzz.i2p.
+For contents of past releases, see the release notes.
+For other project goals, see the meeting notes.
+
          
+Note that we do not have a particular target for numbering a release as "1.0".
+We plan to continue numbering releases as 0.9.x for now.
+We do not maintain separate unstable and stable branches or releases.
+We have a single, stable release path.
+Our normal release cycle is 6-10 weeks.
+
          
+
+
+
+
          0.9.24
          
+
          Target release date: Week of January 25, 2016
          
+
          • 
+SAM v3.2
+
          • 
+Require Java 7
+
          • 
+NetDB Family
+
          • 
+Remove commons-logging
+
          • 
+Use SSU Extended options to request introduction
+
          • 
+Experimental Sybil analysis tool
+
          • 
+Unit test improvements
+
          • 
+Complete transition to Ed25519 signatures for most routers
+
          • 
+Bug fixes, translation updates, geoip updates
+
          
+
+
+
+
+
          0.9.25
          
+
          Target release date: March 2016
          
+
          • 
+Wrapper 3.5.27
+
          • 
+GMP 6.0
+
          • 
+SAM v3.3
+
          • 
+Sybil tool enhancements
+
          • 
+
          • 
+
          • 
+Bug fixes, translation updates, geoip updates
+
          
+
+
+
+
+
          0.9.26
          
+
          Target release date: May 2016
          
+
          • 
+New subscription protocol, addressbook support
+
          • 
+Sybil tool migration to automatic?
+
          • 
+Streaming improvements
+
          • 
+
          • 
+
          • 
+
          • 
+Bug fixes, translation updates, geoip updates
+
          
+
+
+
+
+
+
          0.9.27 - 0.9.29
          
+
          Time frame: 2nd Half 2016
          
+
          • 
+Pluggable transports?
+
          • 
+Crypto migration for existing hidden services
+
          • 
+Initial work on NTCP2
+
          • 
+Initial work on New DH
+
          • 
+Initial work on new crypto
+
          • 
+Initial work on LS2 with multi-destination support
+
          • 
+GMP 6.1
+
          • 
+Initial work on new netdb ("next backend")
+
          • 
+Console redesign phase 1
+
          • 
+Initial work on new naming system with Grothoff
+
          • 
+Jetty 9.2
+
          • 
+Bundle i2pcontrol? (un-pluginize)
+
          • 
+SQLite address book for Android
+
          • 
+Android UI enhancements
+
          • 
+Unit test improvements
+
          • 
+Private test net setup improvements
+
          • 
+Integrated chat client?
+
          • 
+Streaming improvements
+
          • 
+Performance improvements
+
          • 
+Capacity improvements
+
          • 
+NTCP Pumper redesign
+
          • 
+I2PTunnel socket-side NIO
+
          • 
+
          • 
+
          • 
+
          • 
+Bug fixes, translation updates, geoip updates
+
          
+
+
+
+
          2017
          
 
            
-
          • {% trans -%}
-Include some seed data in the distribution so a central reseed location isn't required?
-{%- endtrans %}
            • 
+
          • 
+New crypto
+
          • 
+NTCP2
+
          • 
+LS2 with multi-destination support
+
          • 
+New netdb
+
          • 
+New DH
+
          • 
+Full support for massively popular hidden services
+
          • 
+Initial work on new naming system
+
          • 
+Console redesign phase 2
+
          • 
+Streaming improvements
+
          • 
+Performance improvements
+
          • 
+Capacity improvements
+
            • 
 
          • {% trans todo=site_url('get-involved/todo') -%}
 Reachability Mapping / handle peers partially reachable / enhanced restricted routes
 {%- endtrans %}
            • 
-
          • {% trans %}Improve help pages and website{% endtrans %}
            • 
-
          • {% trans %}More translations{% endtrans %}
            • 
-
          • {% trans %}SSU disconnect message{% endtrans %}
            • 
-
          • {% trans %}Iterative floodfill lookups{% endtrans %}
            • 
-
          
-
-
          1.0
          
-
            
-
          • {% trans %}Full review of anonymity issues and other vulnerabilities{% endtrans %}
            • 
-
          • {% trans -%}
-Reduce memory usage, remove debugging overhead, make it run better on slow and embedded machines
-{%- endtrans %}
            • 
-
          • {{ _('Docs') }}
            • 
-
          
-
-
          2.0
          
-
            
 
          • {% trans %}Full restricted routes{% endtrans %}
            • 
+
          • {% trans %}Tunnel mixing and padding{% endtrans %}
            • 
+
          • {% trans %}User defined message delays{% endtrans %}
            • 
 
          
 
-
          3.0
          
+
+
+
+
          2018
          
 
            
+
          • {% trans todo=site_url('get-involved/todo') -%}
+Reachability Mapping / handle peers partially reachable / enhanced restricted routes
+{%- endtrans %}
            • 
+
          • {% trans %}Full restricted routes{% endtrans %}
            • 
 
          • {% trans %}Tunnel mixing and padding{% endtrans %}
            • 
 
          • {% trans %}User defined message delays{% endtrans %}
            • 
 
          
diff --git a/i2p2www/pages/site/get-involved/todo.html b/i2p2www/pages/site/get-involved/todo.html
index 684fbab9..d6a6bbfa 100644
--- a/i2p2www/pages/site/get-involved/todo.html
+++ b/i2p2www/pages/site/get-involved/todo.html
@@ -28,6 +28,11 @@ Stop & go mix w/ garlics & tunnels
 {% endblock %}
 
 {% block content %}
+
          {% trans roadmap=site_url('get-involved/roadmap') -%}
+Note: This page is not up-to-date.
+See the roadmap for current plans.
+{%- endtrans %}
          
+
 
          {% trans roadmap=site_url('get-involved/roadmap'), volunteer=site_url('get-involved') -%}
 Below is a more detailed (yet still incomplete) discussion of the major areas
 of future development on the core I2P network, spanning the plausibly planned

From d9ad9753eea759f32e22f95d21d51db00f7907a6 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sat, 2 Jan 2016 17:36:11 +0000
Subject: [PATCH 059/114] add release cycle documentation

---
 .../get-involved/guides/dev-guidelines.html   | 46 ++++++++++++++++++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/i2p2www/pages/site/get-involved/guides/dev-guidelines.html b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html
index 68712f3e..20cef19d 100644
--- a/i2p2www/pages/site/get-involved/guides/dev-guidelines.html
+++ b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html
@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}{{ _('Developer Guidelines and Coding Style') }}{% endblock %}
-{% block lastupdated %}{% trans %}November 2015{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %}
 {% block content %}
 
          {% trans newdevs=site_url('get-involved/guides/new-developers') -%}
 Read the new developers guide first.
@@ -31,6 +31,50 @@ the checkin deadline for a release.
 {%- endtrans %}
          • 
 
        
 
+
+
        {{ _('Release Cycle') }}
        
+
        {% trans -%}
+Our normal release cycle is 6-10 weeks.
+Following are the approximate deadlines within a typical 8-week cycle.
+Actual deadlines for each release are set by the lead developer.
+{%- endtrans %}
        
+
+
          
+
        • {% trans -%}
+1-2 days after previous release: Checkins to trunk are allowed.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+2-3 weeks after previous release: Deadline to propagate major changes from other branches to trunk.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+4-5 weeks before release: Deadline to request new home page links.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+3-4 weeks before release: Feature freeze. Deadline for major new features.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+2-3 weeks before release: Hold project meeting to review new home page link requests, if any.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+7-10 days before release: String freeze. No more changes to translated ("tagged") strings.
+Push strings to Transifex, announce translation deadline on Transifex.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+7-10 days before release: Feature deadline. Bug fixes only after this time. No more features, refactoring or cleanup.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+3-4 days before release: Translation deadline. Pull translations from Transifex and check in.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+2-3 days before release: Checkin deadline. No checkins after this time without the permission of the release builder.
+{%- endtrans %}
          • 
+
        • {% trans -%}
+Hours before release: Code review deadline.
+{%- endtrans %}
          • 
+
        
+
+
+
 
        Monotone
        
 
          
 
        • {% trans -%}

From cf485488c4c96d1f28196f6bbfa86423642218de Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sat, 2 Jan 2016 18:06:19 +0000
Subject: [PATCH 060/114] regular meeting schedule

---
 i2p2www/pages/meetings/index.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
index 04bf7781..e537c3f2 100644
--- a/i2p2www/pages/meetings/index.html
+++ b/i2p2www/pages/meetings/index.html
@@ -5,7 +5,8 @@
 {%- endblock %}
 {% block content %}
 
          {% trans mtgforum='http://'+i2pconv('zzz.i2p')+'/forums/20' -%}
-We do not currently have regularly scheduled meetings. Anyone can schedule and
+Regularly scheduled project meetings are held on the first Tuesday of every month at 8 PM UTC.
+Anyone can schedule and
 run a meeting, by posting the agenda in
 the meetings forum.
 {%- endtrans %}
          

From e7b05224eca4e5f4b7af1d470777e349546a2bc8 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sat, 2 Jan 2016 21:32:09 +0000
Subject: [PATCH 061/114] partially revert previous checkin which broke the
 download page

---
 i2p2www/pages/downloads/list.html | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html
index d36baa90..dfe7a392 100644
--- a/i2p2www/pages/downloads/list.html
+++ b/i2p2www/pages/downloads/list.html
@@ -39,10 +39,9 @@ or type java -version at your command prompt.
 
 
 
-{% trans release_notes=site_url('blog/category/release') -%}
 
          {{ _('Release Notes') }}
          
 
-{% endtrans %}
          
 
 
 

From 96029fd419e5843e1fc496a273dedd43f301cda4 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sun, 3 Jan 2016 00:13:11 +0000
Subject: [PATCH 062/114] SAM: Put v3.2 documentation into main part of spec

---
 i2p2www/pages/site/docs/api/samv3.html | 387 +++++++++++++++++++++----
 1 file changed, 333 insertions(+), 54 deletions(-)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index 0df5debf..16c9d90c 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}SAM V3{% endblock %}
-{% block lastupdated %}November 2015{% endblock %}
+{% block lastupdated %}January 2016{% endblock %}
 {% block accuratefor %}0.9.24{% endblock %}
 {% block content %}
 
          Specified below is a simple client protocol for interacting with I2P.
@@ -51,10 +51,9 @@ Version 3.1 was introduced in I2P release 0.9.14.
 
        
 
        
 
-
        Version 3.2 Proposal
        
+
        Version 3.2 Changes
        
 
        
-Version 3.2 is scheduled for inclusion in I2P release 0.9.24, and the changes listed below are preliminary.
-The following changes will be incorporated in the main part of this document soon.
+Version 3.2 was introduced in I2P release 0.9.24.
 
          
 
        • SESSION CREATE now supports options FROM_PORT=nnnn and TO_PORT=nnnn to set default I2P ports
 
        • SESSION CREATE STYLE=RAW now supports option PROTOCOL=nnn to set default I2P protocol (18 otherwise)
@@ -111,6 +110,7 @@ The following changes will be incorporated in the main part of this document soo
 
          Version 3.3 Proposal
          
 
          
 Version 3.3 is not yet implemented, and the changes listed below are preliminary.
+Scheduled for I2P release 0.9.25.
 
            
 
          • The same session ID may be used for streams, datagrams, and raw simultaneously.
     Incoming packets and streams will be routed based on I2P protocol and to-port.
@@ -131,28 +131,11 @@ all of the I2P functionality (using the streaming
 lib for virtual streams, or I2CP directly for async messages).
 
 
            
-All client<-->SAM bridge communication is unencrypted and 
-unauthenticated.  Access to the SAM
-bridge should be protected through firewalls or other means
-(perhaps the bridge may have ACLs on what IPs it accepts 
-connections from).
-
-
            
-All of these SAM messages are sent on a single line in plain ASCII,
-terminated by the newline character (\n).  The formatting shown
-below is merely for readability, and while the first two words in
-each message must stay in their specific order, the ordering of
-the key=value pairs can change (e.g. "ONE TWO A=B C=D" or 
-"ONE TWO C=D A=B" are both perfectly valid constructions).  In
-addition, the protocol is case-sensitive.
-In the following, message examples are preceded by "-> " for
-messages sent by the client to the SAM bridge, and by "<- " for
-messages sent by the SAM bridge to the client.
-
-
            
-SAM messages are interpreted in UTF-8. Key=value pairs must be separated by
-a single space. Values may be enclosed in double quotes if they contain spaces,
-e.g. key="long value text". There is no escaping mechanism.
+The client<-->SAM bridge communication may unencrypted or unauthenticated.
+The SAM bridge may support SSL/TLS connections;
+configuration and implementation details are outside the scope of this specification.
+As of SAM 3.2, optional authentication in the handshake is specified
+and may be required by the bridge..
 
 
            
 I2P communications can take three distinct forms:
@@ -169,6 +152,68 @@ session is bound to an address (called destination). An I2P session
 is associated with one of the three types above, and cannot carry
 communications of another type.
 
            
+
+
+
            Encoding and Escaping
            
+
            
+All of these SAM messages are sent on a single line,
+terminated by the newline character (\n).
+Prior to SAM 3.2, only 7-bit ASCII was supported.
+As of SAM 3.2, the encoding must be UTF-8.
+Any UTF8-encoded keys or values should work.
+
+
            
+The formatting shown in this specification
+below is merely for readability, and while the first two words in
+each message must stay in their specific order, the ordering of
+the key=value pairs can change (e.g. "ONE TWO A=B C=D" or 
+"ONE TWO C=D A=B" are both perfectly valid constructions).
+In addition, the protocol is case-sensitive.
+In the following, message examples are preceded by "-> " for
+messages sent by the client to the SAM bridge, and by "<- " for
+messages sent by the SAM bridge to the client.
+
+
            
+The basic command or response line takes one of the following forms:
+
            +     COMMAND SUBCOMMAND [key=value] [key=value] ...
+     COMMAND                                           # As of SAM 3.2
+     PING[ arbitrary text]                             # As of SAM 3.2
+     PONG[ arbitrary text]                             # As of SAM 3.2
+
            
+COMMAND without a SUBCOMMAND is supported for some new commands in SAM 3.2 only.
+
+
+
            
+Key=value pairs must be separated by
+a single space. (As of SAM 3.2, multiple spaces are allowed)
+Values may be enclosed in double quotes if they contain spaces,
+e.g. key="long value text".
+(Prior to SAM 3.2, this did not work reliably in some implementations)
+
            
+Prior to SAM 3.2, there was no escaping mechanism.
+As of SAM 3.2, double quotes may be escaped with a backslash '\'
+and a backslash may be represented as two backslashes '\\'.
+
            
+
+
+
            Empty values
            
+
            
+As of SAM 3.2,
+empty option values such as KEY, KEY=, or KEY="" may be allowed, implementation dependent.
+
            
+
+
+
            Case Sensitivity
            
+
            
+The protocol, as specified, is case-sensitive.
+It is recommended but not required that the server map commands to upper case, for ease in testing via telnet.
+This would allow, for example, "hello version" to work.
+This is implementation-dependent.
+Do not map keys or values to upper case, as this would corrupt I2CP options.
+
            
+
+
   
 
            SAM Connection Handshake
            
 
            
@@ -176,7 +221,11 @@ No SAM communication can occur until after the client and bridge have
 agreed on a protocol version, which is done by the client sending
 a HELLO and the bridge sending a HELLO REPLY: 
 
            -->  HELLO VERSION MIN=$min MAX=$max
+->  HELLO VERSION
+          [MIN=$min]            # Optional as of SAM 3.1, required for 3.0 and earlier
+          [MAX=$max]            # Optional as of SAM 3.1, required for 3.0 and earlier
+          [USER="xxx"]          # As of SAM 3.2, required if authentication is enabled, see below
+          [PASSWORD="yyy"]      # As of SAM 3.2, required if authentication is enabled, see below
 
            
 and
 
            @@ -186,7 +235,7 @@ and
 
            
 As of version 3.1 (I2P 0.9.14), the MIN and MAX parameters are optional.
 SAM will always return the highest version possible given the
-MIN and MAX constraints, or 3.1 if no constraints are given.
+MIN and MAX constraints, or the current server version if no constraints are given.
 
 If the SAM bridge cannot find a suitable version, it replies with:
 
            @@ -198,6 +247,63 @@ If some error occurred, such as a bad request format, it replies with:
 
            
 
            
 
+
+
            SSL
            
+
            
+The server's control socket may optionally offer SSL/TLS support, as configured on the server and client.
+Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.
+
            
+
+
+
            Authorization
            
+
            
+For authorization, client adds USER="xxx" PASSWORD="yyy" to the HELLO parameters.
+Double quotes for user and password are recommended but not required.
+A double quote inside a user or password must be escaped with a backslash.
+On failure the server will reply with an I2P_ERROR and a message.
+It is recommended that SSL be enabled on any SAM servers where authorization is required.
+
            
+
+
+
            Timeouts
            
+
            
+Servers may implement timeouts for the HELLO or subsequent commands, implementation dependent.
+Clients should promptly send the HELLO and the next command after connecting.
+
            
+If a timeout occurs before the HELLO is received, the bridge replies with:
+
            +<- HELLO REPLY RESULT=I2P_ERROR MESSAGE=$message
+
            
+and then disconnects.
+
            
+If a timeout occurs after the HELLO is received but before the next command, the bridge replies with:
+
            +<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message
+
            
+and then disconnects.
+
            
+
+
+
            I2CP Ports and Protocol
            
+
            
+As of SAM 3.2, the I2CP ports and protocol may be specified by the
+SAM client sender to be passed through to I2CP, and
+the SAM bridge will pass the received I2CP port and protocol
+information to the SAM client.
+
            
+For FROM_PORT and TO_PORT, the valid range is 0-65535, and the default is 0.
+
            
+For PROTOCOL, which may be specified only for RAW, the valid range is 0-255, and the default is 18.
+
            
+For SESSION commands, the specified ports and protocol are the defaults for that session.
+For individual streams or datagrams, the specified ports and protocol override the session defaults.
+For received streams or datagrams, the indicated ports and protocol are as received from I2CP.
+
            
+See the I2CP specification for more information.
+
            
+
+
+
 
            SAM Sessions
            
 
            
 A SAM session is created by a client opening a socket to the SAM 
@@ -210,13 +316,15 @@ Each registered I2P Destination is uniquely associated with a session ID
 
 
            
 Each session is uniquely associated with:
+
            
 
            • 
 the socket from which the client creates the session
 
            • 
 its ID (or nickname)
 
            
 
-
            
+
            Session Creation Request
            
+
            
 The session creation message can only use one of these forms (messages 
 received through other forms are answered with an error message) :
 
@@ -225,6 +333,10 @@ received through other forms are answered with an error message) :
           STYLE={STREAM,DATAGRAM,RAW}
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
+          [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
+          [TO_PORT=nnn]                        # SAM 3.2 or higher only, default 0
+          [PROTOCOL=nnn]                       # SAM 3.2 or higher only, for STYLE=RAW only, default 18
+          [HEADER={true,false}]                # SAM 3.2 or higher only, for STYLE=RAW only, default false
           [option=value]*
 
            
 
@@ -259,8 +371,10 @@ The SAM bridge itself should already be configured with what router
 it should communicate over I2P through (though if need be there may
 be a way to provide an override, e.g. i2cp.tcp.host=localhost and 
 i2cp.tcp.port=7654).
+
            
 
-
            
+
            Session Creation Response
            
+
            
 After receiving the session create message, the SAM bridge will reply
 with a session status message, as follows:
 
@@ -332,19 +446,24 @@ he wants to listen to requests coming from other I2P destinations.
 
            SAM Virtual Streams : CONNECT
            
 
            
 A client asks for a connection by:
+
            
 
            • 
 opening a new socket with the SAM bridge
 
            • 
 passing the same HELLO handshake as above
 
            • 
-sending the STREAM CONNECT command:  
+sending the STREAM CONNECT command  
 
            
 
+
            Connect Request
            
+
            
 
             -> STREAM CONNECT
          ID=$nickname
          DESTINATION=$destination
-         [SILENT={true,false}]
+         [SILENT={true,false}]                # default false
+         [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
+         [TO_PORT=nnn]                        # SAM 3.2 or higher only, default 0
 
            
 
 
            
@@ -355,8 +474,10 @@ whose ID is $nickname to the specified peer.
 The target is $destination, which is the base 64 of the Destination,
 which is 516 or more base 64 characters (387 or more bytes in binary),
 depending on signature type.
+
            
 
-
            
+
            Connect Response
            
+
            
 If SILENT=true is passed, the SAM bridge won't issue any other message
 on the socket. If the connection fails, the socket will be closed.
 If the connection succeeds, all remaining data passing through the
@@ -398,25 +519,34 @@ socket.
 
            SAM Virtual Streams : ACCEPT
            
 
            
 A client waits for an incoming connection request by:
+
            
 
            • 
 opening a new socket with the SAM bridge
 
            • 
 passing the same HELLO handshake as above
 
            • 
-sending the STREAM ACCEPT command:  
+sending the STREAM ACCEPT command  
 
            
 
+
            Accept Request
            
+
            
 
             -> STREAM ACCEPT
          ID=$nickname
-         [SILENT={true,false}]
+         [SILENT={true,false}]                # default false
 
            
 
 
            
 This makes the session ${nickname} listen for one incoming
 connection request from the I2P network.
-
 
            
+As of SAM 3.2,
+multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port).
+Prior to 3.2, concurrent accepts would fail with ALREADY_ACCEPTING.
+
            
+
+
            Accept Response
            
+
            
 If SILENT=true is passed, the SAM bridge won't issue any other message
 on the socket. If the accept fails, the socket will be closed.
 If the accept succeeds, all remaining data passing through the
@@ -460,7 +590,16 @@ peer.
 
            
 If SILENT=false was passed, which is the default value, the SAM bridge
 sends the client a ASCII line containing the base64 public destination key
-of the requesting peer. After this '\n' terminated line, all remaining data 
+of the requesting peer, and additional information for SAM 3.2 only:
+
+
            +    $destination
+    FROM_PORT=nnn                      # SAM 3.2 or higher only
+    TO_PORT=nnn                        # SAM 3.2 or higher only
+    \n
+
            
+
+After this '\n' terminated line, all remaining data 
 passing through the current socket is forwarded from and to the connected
 I2P destination peer, until one of the peer closes the socket.
 
            
@@ -469,27 +608,33 @@ I2P destination peer, until one of the peer closes the socket.
 
            
 A client can use a regular socket server and wait for connection requests
 coming from I2P. For that, the client must:
+
            
 
            • 
 open a new socket with the SAM bridge
 
            • 
 pass the same HELLO handshake as above
 
            • 
-send the forward command:
+send the forward command
 
            • 
 
+
            Forward Request
            
+
            
 
             -> STREAM FORWARD
          ID=$nickname
          PORT=$port
          [HOST=$host]
-         [SILENT={true,false}]
+         [SILENT={true,false}]                # default false
+         [SSL={true,false}]                   # SAM 3.2 or higher only, default false
 
            
 
 
            
 This makes the session ${nickname} listen for incoming
 connection requests from the I2P network.
+
            
 
-
            
+
            Forward Response
            
+
            
 SILENT defaults to false.
 Whether SILENT is true or false,
 the SAM bridge always answers with a STREAM STATUS message.
@@ -534,11 +679,22 @@ peer.
 
            
 If SILENT=false was passed, which is the default value, the SAM bridge
 sends on the obtained socket an ASCII line containing the base64 public
-destination key of the requesting peer. After this '\n' terminated line,
+destination key of the requesting peer, and additional information for SAM 3.2 only:
+
+
            +    $destination
+    FROM_PORT=nnn                      # SAM 3.2 or higher only
+    TO_PORT=nnn                        # SAM 3.2 or higher only
+    \n
+
            
+
+After this '\n' terminated line,
 all remaining data passing through the socket is forwarded from and to 
 the connected I2P destination peer, until one of the sides closes the
 socket.
 
+
            
+As of SAM 3.2, if SSL=true is specified, the forwarding socket is over SSL/TLS.
 
 
 
            
@@ -560,6 +716,7 @@ signing key to verify the source) and includes replay prevention.
 
            
 Minimum size is 1. For best delivery reliability, recommended maximum
 size is approximately 11 KB.
+Reliability is inversely proportional to message size, perhaps even exponentially.
 
 
            
 After establishing a SAM session with STYLE=DATAGRAM, the client can
@@ -567,14 +724,20 @@ send datagrams through SAM's UDP port (7655).
 
 
            
 The first line of a datagram sent through this port must be in the
-following format:
+following format.
+This is all on one line (space separated), shown on multiple lines for clarity:
 
-
            
-3.0 $nickname $destination
-
            
+
            +    3.0                                  # As of SAM 3.2, any 3.x is allowed
+    $nickname
+    $destination
+    [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
+    [TO_PORT=nnn]                        # SAM 3.2 or higher only, default 0
+    \n
+
            
 
 
            • 
- 3.0 is the version of SAM
+ 3.0 is the version of SAM. As of SAM 3.2, any 3.x is allowed.
 
            • 
  $nickname is the id of the DATAGRAM session that will be used
 
            • 
@@ -606,7 +769,10 @@ message:
 
               <-  DATAGRAM RECEIVED
            DESTINATION=$destination
-           SIZE=$numBytes\n
+           SIZE=$numBytes
+           FROM_PORT=nnn                      # SAM 3.2 or higher only
+           TO_PORT=nnn                        # SAM 3.2 or higher only
+           \n
        [$numBytes of data]
 
              
 
@@ -634,6 +800,9 @@ CREATE command with PORT and HOST options:
           DESTINATION={$privkey,TRANSIENT}
           PORT=$port
           [HOST=$host]
+          [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
+          [TO_PORT=nnn]                        # SAM 3.2 or higher only, default 0
+          [PROTOCOL=nnn]                       # SAM 3.2 or higher only, for STYLE=RAW only, default 18
           [option=value]*
 
      
 
@@ -667,8 +836,11 @@ When a repliable datagram arrives, the bridge sends to the specified host:port
 a UDP packet containing the following data:
 
 
      -$destination\n
-$datagram_payload
+    $destination
+    FROM_PORT=nnn                      # SAM 3.2 or higher only
+    TO_PORT=nnn                        # SAM 3.2 or higher only
+    \n
+    $datagram_payload
 
      
 
 
      
@@ -677,9 +849,21 @@ to the specified host:port without a prefix.
 The UDP packet contains the following data:
 
 
      -$datagram_payload
+          $datagram_payload
 
      
 
+As of SAM 3.2, when HEADER=true is specified in SESSION CREATE,
+the forwarded raw datagram will be prepended with a header line as follows:
+
+
      +          FROM_PORT=nnn
+          TO_PORT=nnn
+          PROTOCOL=nnn
+          \n
+          $datagram_payload
+
      
+
+
 
      
 The $destination is the base 64 of the Destination,
 which is 516 or more base 64 characters (387 or more bytes in binary),
@@ -714,7 +898,11 @@ command. This is the v1/v2-compatible way of receiving datagrams.
 
 
       <- RAW RECEIVED
-          SIZE=$numBytes\n
+          SIZE=$numBytes
+          FROM_PORT=nnn                      # SAM 3.2 or higher only
+          TO_PORT=nnn                        # SAM 3.2 or higher only
+          PROTOCOL=nnn                       # SAM 3.2 or higher only
+          \n
       [$numBytes of data]
 
      
 
@@ -724,9 +912,21 @@ the bridge sends to the specified host:port a message containing
 the following data:
 
 
      -$datagram_payload
+          $datagram_payload
 
      
 
+As of SAM 3.2, when HEADER=true is specified in SESSION CREATE,
+the forwarded raw datagram will be prepended with a header line as follows:
+
+
      +          FROM_PORT=nnn
+          TO_PORT=nnn
+          PROTOCOL=nnn
+          \n
+          $datagram_payload
+
      
+
+
 
      
 For an alternate method of sending anonymous datagrams, see RAW SEND.
 
      
@@ -743,6 +943,12 @@ As of release 0.9.14 (version 3.1), anonymous datagrams may be sent
 directly via the SAM bridge socket using the RAW SEND command,
 as documented in SAM V1 and SAM V2.
 
+
      
+As of release 0.9.24 (version 3.2), DATAGRAM SEND and RAW SEND may include
+the parameters FROM_PORT=nnnn and/or TO_PORT=nnnn to override the default ports.
+As of release 0.9.24 (version 3.2), RAW SEND may include
+the parameter PROTOCOL=nnn to override the default protocol.
+
 
      
 These commands do not support the ID parameter. The datagrams are
 sent to the most recently created DATAGRAM- or RAW-style session,
@@ -751,6 +957,8 @@ as appropriate. Support for the ID parameter may be added in a future release.
 
 
 
      SAM Utility Commands
      
+
+
      Host Name Lookup
      
 
      
 The following message can be used by the client to query the SAM
 bridge for name resolution:
@@ -793,6 +1001,7 @@ which is 516 or more base 64 characters (387 or more bytes in binary),
 depending on signature type.
 
 
+
      Destination Key Generation
      
 
      
 Public and private base64 keys can be generated using the following
 message:
@@ -829,6 +1038,73 @@ which is 884 or more base 64 characters (663 or more bytes in binary),
 depending on signature type.
 The binary format is specified in Private Key File.
 
+
+
      PING/PONG (SAM 3.2 or higher)
      
+
      
+Either the client or server may send:
+
      +    PING[ arbitrary text]
+
      
+on the control port,
+with the response:
+
      +    PONG[ arbitrary text from the ping]
+
      
+to be used for control socket keepalive.
+Either side may close the session and socket if no response is received in a reasonable time, implementation dependent.
+
      
+If a timeout occurs waiting for a PONG from the client, the bridge may send:
+
      +<- SESSION STATUS RESULT=I2P_ERROR MESSAGE=$message
+
      
+and then disconnect.
+
      
+If a timeout occurs waiting for a PONG from the bridge, the client may simply disconnect.
+
      
+
+
+
      QUIT/STOP/EXIT (SAM 3.2 or higher, optional features)
      
+
      
+Commands QUIT, STOP and EXIT will close the session and socket.
+Implementation is optional, for ease in testing via telnet.
+Whether there is any response before the socket is closed
+(for example, a SESSION STATUS message) is
+implementation-specific and outside the scope of this specification.
+
      
+
+
+
      HELP (optional feature)
      
+
      
+Servers may implement a HELP command.
+Implementation is optional, for ease in testing via telnet.
+Output format and detection of the end of the output is
+implementation-specific and outside the scope of this specification.
+
      
+
+
+
+
      Authorization Configuration (SAM 3.2 or higher, optional feature)
      
+
      
+Authorization configuration using the AUTH command.
+A SAM server may implement these commands to facilite persistent storage of credentials.
+Configuration of authentication other than with these commands is
+implementation-specific and outside the scope of this specification.
+
      
+
        
+    
      • AUTH ENABLE enables authorization on subsequent connections
+    
      • AUTH DISABLE disables authorization on subsequent connections
+    
      • AUTH ADD USER="foo" PASSWORD="bar" adds a user/password
+    
      • AUTH REMOVE USER="foo" removes this user
+
      
+
      
+Double quotes for user and password are recommended but not required.
+A double quote inside a user or password must be escaped with a backslash.
+On failure the server will reply with an I2P_ERROR and a message.
+
      
+
+
+
+
 
      RESULT Values
      
 
      
 These are the values that can be carried by the RESULT field, with
@@ -872,12 +1148,15 @@ Some may be older and have not been updated for SAMv3 support.
 
 
      Default SAM Setup
      
 
      
-The default SAM port is 7656. SAM is not enabled by default in the I2P Router;
+The default SAM port is 7656. SAM is not enabled by default in the Java I2P Router;
 it must be started manually, or configured to start automatically,
 on the configure clients page in the router console, or in the clients.config file.
-The default SAM UDP port is 7655, listening on 0.0.0.0.
+The default SAM UDP port is 7655, listening on 127.0.0.1.
 These may be changed by adding the arguments sam.udp.port=nnnnn and/or
 sam.udp.host=w.x.y.z to the invocation.
 
+
      
+Configuration in other routers is implementation-specific.
+
 
      
 {% endblock %}

From 516f0dc867bd715a8f2eccc2ec05eefad4da4440 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sun, 3 Jan 2016 13:20:58 +0000
Subject: [PATCH 063/114] SAM: Simplify list of 3.2 changes since the details
 are now in the main part of the spec

---
 i2p2www/pages/site/docs/api/samv3.html | 74 ++++++++++++--------------
 1 file changed, 33 insertions(+), 41 deletions(-)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index 16c9d90c..74bda143 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -54,56 +54,48 @@ Version 3.1 was introduced in I2P release 0.9.14.
 
      Version 3.2 Changes
      
 
      
 Version 3.2 was introduced in I2P release 0.9.24.
+
      
+
+
      I2CP Port and Protocol Support
      
 
        
-
      • SESSION CREATE now supports options FROM_PORT=nnnn and TO_PORT=nnnn to set default I2P ports
-
      • SESSION CREATE STYLE=RAW now supports option PROTOCOL=nnn to set default I2P protocol (18 otherwise)
-
      • STREAM CONNECT, DATAGRAM SEND, and RAW SEND now support new options FROM_PORT=nnnn and TO_PORT=nnnn
-    to override default I2P ports for that connection
-
      • RAW SEND now supports option PROTOCOL=nnn to override default I2P RAW protocol value (18)
+
      • SESSION CREATE options FROM_PORT and TO_PORT
+
      • SESSION CREATE STYLE=RAW option PROTOCOL
+
      • STREAM CONNECT, DATAGRAM SEND, and RAW SEND options FROM_PORT and TO_PORT
+
      • RAW SEND option PROTOCOL
 
      • DATAGRAM RECEIVED, RAW RECEIVED, and forwarded or received streams and repliable datagrams,
-    now appends to the first line is FROM_PORT=nnnn TO_PORT=nnnn to indicate I2P ports
-
      • For a RAW session forwarded to an external port, if the option HEADER=true is provided,
-    the forwarded raw datagram will be prepended with a line containing PROTOCOL=nnn FROM_PORT=nnnn TO_PORT=nnnn
-    The line ends with \n.
+    includes FROM_PORT and TO_PORT
+
      • RAW session option HEADER=true will cause
+    the forwarded raw datagrams to be prepended with a line containing PROTOCOL=nnn FROM_PORT=nnnn TO_PORT=nnnn
 
      • The first line of datagrams sent through port 7655 may now start with any 3.x version
-
      • The first line of datagrams sent through port 7655 may have, after the destination,
-    any of the options FROM_PORT=nnnn TO_PORT=nnnn PROTOCOL=nnn
-
      • RAW RECEIVED now appends to the first line PROTOCOL=nnn to indicate I2P protocol
-
      • Client and server may now send: PING [arbitrary text] on the control port,
-    with the response:
-    PONG [arbitrary text from the ping], to be used for control socket keepalive.
-    Either side may close the session and socket if no response is received in a reasonable time, implementation dependent.
-
      • For authorization, client adds USER="xxx" PASSWORD="yyy" to the HELLO parameters.
-    Double quotes for user and password are recommended but not required.
-    A double quote inside a user or password must be escaped with a backslash.
-    On failure the server will reply with an I2P_ERROR and a message.
-
      • (optional feature) Authorization configuration with the AUTH command.
-    A SAM server may implement these commands to facilite persistent storage of credentials.
-  
          
-    
        • AUTH ENABLE enables authorization on subsequent connections
-    
        • AUTH DISABLE disables authorization on subsequent connections
-    
        • AUTH ADD USER="foo" PASSWORD="bar" adds a user/password
-    
        • AUTH REMOVE USER="foo" removes this user
-  
        
-    Double quotes for user and password are recommended but not required.
-    A double quote inside a user or password must be escaped with a backslash.
-    On failure the server will reply with an I2P_ERROR and a message.
-
      • Multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port).
-    Prior to 3.2, concurrent accepts would fail with ALREADY_ACCEPTING.
-
      • The server's control socket may optionally offer SSL/TLS support, as configured on the server and client.
-    Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.
-
      • For STREAM FORWARD, client may add SSL=true to use an SSL socket
-
      • New commands QUIT, STOP and EXIT will close the session and socket. Implementation is optional,
-    for ease in testing via telnet.
+
      • The first line of datagrams sent through port 7655 may contain
+    any of the options FROM_PORT, TO_PORT, PROTOCOL
+
      • RAW RECEIVED includes PROTOCOL=nnn
+
      
+
+
      SSL and Authentication
      
+
        
+
      • USER/PASSWORD in the HELLO parameters for authorization. See below.
+
      • Optional authorization configuration with the AUTH command. See below.
+
      • Optional SSL/TLS support on the control socket
+
      • STREAM FORWARD option SSL=true
+
      
+
+
      Multithreading
      
+
        
+
      • Concurrent pending STREAM ACCEPTs are allowed on the same session ID.
+
      
+
+
      Command Line Parsing and Keepalive
      
+
        
+
      • Optional commands QUIT, STOP and EXIT to close the session and socket. See below.
 
      • Command parsing will properly handle UTF-8
 
      • Command parsing reliably handles whitespace inside quotes
 
      • A backslash '\' may escape quotes on the command line
-
      • It is recommended but not required that the server map commands to upper case, for ease in testing via telnet.
-    Do not map keys to upper case, as this would corrupt I2CP options.
+
      • Recommended that the server map commands to upper case, for ease in testing via telnet.
 
      • Empty option values such as PROTOCOL or PROTOCOL= may be allowed, implementation dependent.
+
      • PING/PONG for keepalive. See below.
 
      • Servers may implement timeouts for the HELLO or subsequent commands, implementation dependent.
 
      
-
      
 
 
 

From 57ec5244dfab05f0d3c733bc915befe9bee94485 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sun, 3 Jan 2016 16:37:29 +0000
Subject: [PATCH 064/114] Note that simultaneous FORWARD and ACCEPT is
 disallowed

---
 i2p2www/pages/site/docs/api/samv3.html | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index 74bda143..254dc6f2 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -531,6 +531,7 @@ sending the STREAM ACCEPT command
 
      
 This makes the session ${nickname} listen for one incoming
 connection request from the I2P network.
+ACCEPT is not allowed while there is an active FORWARD on the session.
 
      
 As of SAM 3.2,
 multiple concurrent pending STREAM ACCEPTs are allowed on the same session ID (even with the same port).
@@ -623,6 +624,7 @@ send the forward command
 
      
 This makes the session ${nickname} listen for incoming
 connection requests from the I2P network.
+FORWARD is not allowed while there is a pending ACCEPT on the session.
 
      
 
 
      Forward Response
      

From 1fe01d7d24e45efe6ea46636e761279f2c9c7698 Mon Sep 17 00:00:00 2001
From: zzz 
Date: Mon, 4 Jan 2016 16:51:10 +0000
Subject: [PATCH 065/114] sam tweaks

---
 i2p2www/pages/site/docs/api/samv3.html | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index 254dc6f2..9bd80608 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -325,6 +325,8 @@ received through other forms are answered with an error message) :
           STYLE={STREAM,DATAGRAM,RAW}
           ID=$nickname
           DESTINATION={$privkey,TRANSIENT}
+          [PORT=$port]                         # Required for DATAGRAM and RAW, invalid for STREAM
+          [HOST=$host]                         # Optional for DATAGRAM and RAW, invalid for STREAM
           [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
           [TO_PORT=nnn]                        # SAM 3.2 or higher only, default 0
           [PROTOCOL=nnn]                       # SAM 3.2 or higher only, for STYLE=RAW only, default 18
@@ -846,6 +848,7 @@ The UDP packet contains the following data:
           $datagram_payload
    • +

    As of SAM 3.2, when HEADER=true is specified in SESSION CREATE, the forwarded raw datagram will be prepended with a header line as follows: From 5017942e634ac8a185d4cac26f2e82234f9f90dd Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 4 Jan 2016 16:53:35 +0000 Subject: [PATCH 066/114] Promote Sadie to PR Manager Add psi as Technical PR Advisor Add Release Manager alternates --- i2p2www/pages/site/about/team.html | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/about/team.html b/i2p2www/pages/site/about/team.html index 97177404..8bbef9e6 100644 --- a/i2p2www/pages/site/about/team.html +++ b/i2p2www/pages/site/about/team.html @@ -1,5 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{{ _('I2P Project Members') }}{% endblock %} +{% block lastupdated %}January 2016{% endblock %} {% block content %}

    {% trans volunteer=site_url('get-involved') -%} We are a small group of people spread around several continents, working to @@ -10,7 +11,7 @@ network. - + @@ -22,7 +23,7 @@ network. - + @@ -30,6 +31,11 @@ network. + + + + + @@ -65,6 +71,11 @@ network. + + + + + From 8a8cf68eacf044c3af34956a840775a67e20d43c Mon Sep 17 00:00:00 2001 From: zzz Date: Thu, 7 Jan 2016 17:28:46 +0000 Subject: [PATCH 067/114] Added details on plugin classpath (ticket #1679) Updated info on JRE versions --- i2p2www/pages/site/docs/spec/plugin.html | 112 ++++++++++++++++++----- 1 file changed, 88 insertions(+), 24 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/plugin.html b/i2p2www/pages/site/docs/spec/plugin.html index 1cf789a9..fc78ec7e 100644 --- a/i2p2www/pages/site/docs/spec/plugin.html +++ b/i2p2www/pages/site/docs/spec/plugin.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2P Plugin Specification{% endblock %} -{% block lastupdated %}May 2015{% endblock %} -{% block accuratefor %}0.9.20{% endblock %} +{% block lastupdated %}January 2016{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %}

    Overview

    @@ -451,19 +451,81 @@ Classpaths The following jars in $I2P/lib can be assumed to be in the standard classpath for all I2P installations, no matter how old or how new the original installation: -

    - i2p.jar, router.jar, jbigi.jar, sam.jar, mstreaming.jar, streaming.jar, i2ptunnel.jar, - org.mortbay.jetty.jar, javax.servlet.jar, jasper-compiler.jar, jasper-runtime.jar, - commons-logging.jar, commons-el.jar, wrapper.jar, systray.jar, systray4j.jar -

    +

    {{ _('Admin') }}{{ _('Admin') }} {{ _('Project Manager') }} zzz {{ _('point of contact of last resort') }}
    {{ _('PR manager') }}psiSadie {{ _('press contact, manages public relations and affairs') }}
    Meeh {{ _('Public speaking, public relations assistance') }}
    {{ _('Technical PR advisor') }}psi{{ _('Public relations assistance') }}
    {% trans forum=i2pconv('forum.i2p') %}Forum admin{% endtrans %} cervanteszzz {{ _('Builds and signs the releases') }}
    {{ _('Release Manager Alternates') }}eche|on, kytv, str4d{{ _('Backup release managers') }}
    {{ _('Update admin') }} KillYourTV
    +
    JarContainsUsage +
    commons-logging.jar +Apache LoggingFor plugins requiring Apache logging. +Prior to Jetty 6 (release 0.9), +this contained Apache Commons Logging only. +From release 0.9 to release 0.9.23, +this contained both Commons Logging and Tomcat JULI. +As of release 0.9.24. +this contains Apache Tomcat JULI logging only. +
    commons-el.jar +JSP Expression LanguageFor plugins with JSPs that use EL + +
    i2p.jar +Core APIAlmost all plugins will need + +
    i2ptunnel.jar +I2PTunnelFor plugins with HTTP or other servers + +
    jasper-compiler.jar +nothingEmpty since Jetty 6 (release 0.9) + +
    jasper-runtime.jar +Jasper Complier and Runtime, and some Tomcat utilsNeeded for plugins with JSPs + +
    javax.servlet.jar +Servlet APINeeded for plugins with JSPs + +
    jbigi.jar +BinariesNo plugin should need + +
    mstreaming.jar +Streaming APIAlmost all plugins will need + +
    org.mortbay.jetty.jar +Jetty BaseOnly plugins starting their own Jetty instance will need. +Recommended way of starting Jetty is with net.i2p.jetty.JettyStart in jetty-i2p.jar. + +
    router.jar +RouterOnly plugins using router context will need; most will not + +
    sam.jar +SAMNo plugin should need + +
    streaming.jar +Streaming ImplementationAlmost all plugins will need + +
    systray.jar +URL LauncherMost plugins should not need + +
    systray4j.jar +SystrayNo plugin should need + +
    wrapper.jar +RouterMost plugins should not need + +
    + +

    The following jars in $I2P/lib can be assumed to be present for all I2P installations, no matter how old or how new the original installation, but are not necessarily in the classpath:

    - jstl.jar, standard.jar -

    + +
    JarContainsUsage +
    jstl.jar +Standard TaglibFor plugins using JSP tags +
    standard.jar +Standard TaglibFor plugins using JSP tags + +
    + +

    Anything not listed above may not be present in everybody's classpath, even if you have it in the classpath in YOUR version of i2p. If you need any jar not listed above, add $I2P/lib/foo.jar to the classpath specified @@ -481,34 +543,36 @@ Therefore, specify the full required classpath for each client.

    Java Version Notes

    -While most I2P users are running a 1.6 (6.0) JVM, we support 1.5 (5.0) and higher JVMs. -Unless you require 1.6 features, you should create your plugin so it works on 1.5. +I2P has required Java 7 since release 0.9.24 (January 2016). +I2P has required Java 6 since release 0.9.12 (April 2014). +Any I2P users on the latest release should be running a 1.7 (7.0) JVM. +In early 2016, +unless you require 1.7 language or library features, you should create your plugin so it works on 1.6. +Later in the year, most of the network will be on 0.9.24 or higher with Java 7.

    -If your plugin does not require 1.6: +If your plugin does not require 1.7:

    • -Ensure that all java and jsp files are compiled with source="1.5" target="1.5". +Ensure that all java and jsp files are compiled with source="1.6" target="1.6", +or source="1.5" target="1.5",
    • -Ensure that all bundled library jars are also for 1.5 or lower. -
    • -If you are using pack200, any 1.6 classes in a jar will -cause pack200 to create a 1.6 pack format, and -plugin installation will fail on a 1.5 system -with the misleading message "plugin is corrupt". +Ensure that all bundled library jars are also for 1.6 or lower.

    -If your plugin requires 1.6: +If your plugin requires 1.7:

    • Note that on your download page.
    • -Add min-java-version=1.6 to your plugin.config -
    • -If you are using pack200, plugin installation will fail on a 1.5 system -with the misleading message "plugin is corrupt". +Add min-java-version=1.7 to your plugin.config
    +

    +In any case, you must set a bootclasspath when compiling with Java 8 +to prevent runtime crashes. +

    +

    JVM Crashes When Updating From 5b8e0c05e06ded304eb763cc4e04f427513cc284 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 8 Jan 2016 15:03:30 +0000 Subject: [PATCH 068/114] add recent talks --- i2p2www/pages/site/about/media.html | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/i2p2www/pages/site/about/media.html b/i2p2www/pages/site/about/media.html index fe625c42..c9d4e61b 100644 --- a/i2p2www/pages/site/about/media.html +++ b/i2p2www/pages/site/about/media.html @@ -105,6 +105,19 @@ Blair Dick, University of Abertay, Dundee Ethical Hacking Society, January 25, 2 Toronto, August 15-16, 2015 {%- endtrans %}

    • +
  • {% trans link='https://download.i2p2.de/media/ccc/2015/I2P_Still_alive.pdf' -%} +I2P - Still alive! +echelon, 32C3 Hamburg, December 28, 2015 +{%- endtrans %}
    • + +
  • {% trans link='https://download.i2p2.de/media/rwc/2016/rwc2016-str4d-slides.pdf', +link2='https://download.i2p2.de/media/rwc/2016/rwc2016-str4d-slides.odp' -%} +Replacing Weary Crypto: Upgrading the I2P network with stronger primitives +(pdf) +(odp) +str4d, Real World Crypto, Stanford, January 8, 2016 +{%- endtrans %}
    • +

    {{ _('Tutorials') }}

    From 8d2b8cca7f624a33d9a9a4030417b4d8b534b68e Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 8 Jan 2016 15:15:37 +0000 Subject: [PATCH 069/114] add podcast entries --- i2p2www/pages/site/about/media.html | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/i2p2www/pages/site/about/media.html b/i2p2www/pages/site/about/media.html index c9d4e61b..dccfda40 100644 --- a/i2p2www/pages/site/about/media.html +++ b/i2p2www/pages/site/about/media.html @@ -236,6 +236,16 @@ November 11, 2011. February 16, 2012 {%- endtrans %} +
  • {% trans mp3='http://traffic.libsyn.com/brakeingsecurity/2015-010-I2P_dev_interview.mp3' -%} +Jeff and Str4d interviewed on the Brakeing Down Security Podcast Ep. 2015-010 (mp3) +Part 1, February 28, 2015 +{%- endtrans %}
    • + +
  • {% trans mp3='http://traffic.libsyn.com/brakeingsecurity/2015-011-part2-i2p.mp3' -%} +Jeff and Str4d interviewed on the Brakeing Down Security Podcast Ep. 2015-011 (mp3) +Part 2, March 6, 2015 +{%- endtrans %}
    • +

    {{ _('Other') }}

    From 4aba81a5ac3bdd84842a0165ef717f4e49026a45 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 10 Jan 2016 22:18:00 +0000 Subject: [PATCH 070/114] spec updates --- i2p2www/pages/site/docs/spec/i2np.html | 40 ++++++++++++++++++- .../pages/site/docs/spec/tunnel-creation.html | 22 ++++++---- 2 files changed, 53 insertions(+), 9 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/i2np.html b/i2p2www/pages/site/docs/spec/i2np.html index cfce8ef1..dfb3c85b 100644 --- a/i2p2www/pages/site/docs/spec/i2np.html +++ b/i2p2www/pages/site/docs/spec/i2np.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2NP Specification{% endblock %} -{% block lastupdated %}January 2015{% endblock %} -{% block accuratefor %}0.9.17{% endblock %} +{% block lastupdated %}January 2016{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %}

    The I2P Network Protocol (I2NP), @@ -177,6 +177,9 @@ some places in the protocol stack. However, for compatibility with older versions, checksum generation is still required. It is a topic for future research to determine points in the protocol stack where the far-end router's version is known and checksum generation can be disabled. +

  • +The short expiration is unsigned and will wrap around on Feb. 7, 2106. +As of that date, an offset must be added to get the correct time.
    • @@ -585,8 +588,18 @@ Total length: Typical length is: VariableTunnelBuildReply 24 + + Reserved for experimental messages + 224 - 254 + + + Reserved for future expansion + 255 + + +

    DatabaseStore

    Description

    @@ -1130,6 +1143,17 @@ data :: +----+----+----+----+----+-//-+ {% endhighlight %} +

    Notes

    +
      +
    • + This message contains no routing information and will never be sent "unwrapped". + It is only used inside Garlic messages. +
    + + + + +

    Definition

    {% highlight lang='dataspec' %} length :: @@ -1171,6 +1195,10 @@ total size: 8*528 = 4224 bytes See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification. +
  • + While this message is rarely seen in today's network, having been replaced by the VariableTunnelBuild message, + it may still be used for very long tunnels, and has not been deprecated. + Routers must implement. @@ -1185,6 +1213,10 @@ Same format as `TunnelBuildMessage`, with `BuildResponseRecord`s See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification. +
  • + While this message is rarely seen in today's network, having been replaced by the VariableTunnelBuildReply message, + it may still be used for very long tunnels, and has not been deprecated. + Routers must implement.

    VariableTunnelBuild

    @@ -1215,6 +1247,8 @@ total size: 1+$num*528 See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification. +
  • + Typical number of records in today's network is 5.

    VariableTunnelBuildReply

    @@ -1238,6 +1272,8 @@ Same format as `VariableTunnelBuildMessage`, with `BuildResponseRecord`s. See also the tunnel creation specification.
  • The I2NP message ID for this message must be set according to the tunnel creation specification. +
  • + Typical number of records in today's network is 5. diff --git a/i2p2www/pages/site/docs/spec/tunnel-creation.html b/i2p2www/pages/site/docs/spec/tunnel-creation.html index 53c86d90..eb233ac1 100644 --- a/i2p2www/pages/site/docs/spec/tunnel-creation.html +++ b/i2p2www/pages/site/docs/spec/tunnel-creation.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}Tunnel Creation{% endblock %} -{% block lastupdated %}September 2014{% endblock %} -{% block accuratefor %}0.9.15{% endblock %} +{% block lastupdated %}January 2016{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %} This page documents the current tunnel build implementation. @@ -130,9 +130,19 @@ records contained within it for one starting with their own identity hash (trimmed to 16 bytes). It then decrypts the ElGamal block from that record and retrieves the protected cleartext. At that point, they make sure the tunnel request is not a duplicate by feeding the -AES-256 reply key into a bloom filter. -Duplicates or invalid requests -are dropped.

    +AES-256 reply key into a Bloom filter. +Duplicates or invalid requests are dropped. +Records that are not stamped with the current hour, +or the previous hour if shortly after the top of the hour, +must be dropped. +For example, take the hour in the timestamp, convert to a full time, +then if it's more than 65 minutes behind or 5 minutes ahead of the +current time, it is invalid. +The Bloom filter must have a duration of at least one hour +(plus a few minutes, to allow for clock skew), +so that duplicate records in the current hour that are not rejected +by checking the hour timestamp in the record, will be rejected by the filter. +

    After deciding whether they will agree to participate in the tunnel or not, they replace the record that had contained the request with @@ -332,8 +342,6 @@ we should do so.

  • Further analysis of possible tagging and timing attacks described in the above notes.
  • -The Bloom filter rotation time should be evaluated. -
  • Use only VTBM; do not select old peers that don't support it.
  • The Build Request Record does not specify a tunnel lifetime or expiration; From 644591a98726634846d3c79fb6afce14750a1ae3 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 12 Jan 2016 15:39:19 +0000 Subject: [PATCH 071/114] preliminary family docs --- .../pages/site/docs/how/network-database.html | 51 ++++++++++++++++--- 1 file changed, 43 insertions(+), 8 deletions(-) diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index 60bd79be..83d98742 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}The Network Database{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.23{% endblock %} +{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %}

    {% trans %}Overview{% endtrans %}

    @@ -36,6 +36,8 @@ as the key. The structure itself contains:
  • {% trans %}The signature of the above, generated by the identity's signing key{% endtrans %}
    • +

    {% trans %}Expected Options{% endtrans %}

    +

    {% trans -%} The following text options, while not strictly required, are expected to be present: @@ -86,6 +88,7 @@ Above the minimum threshold, the advertised bandwidth is not used or trusted any in the router, except for display in the user interface and for debugging and network analysis. {%- endtrans %}

    +

    {% trans %}Additional Options{% endtrans %}

    {% trans stats=i2pconv('stats.i2p') -%} Additional text options include @@ -113,12 +116,35 @@ As the network has matured, we have gradually removed most of the published statistics to improve anonymity, and we plan to remove more in future releases. {%- endtrans %}

    -

    - {% trans %}RouterInfo specification{% endtrans %} -

    -

    - {% trans %}RouterInfo Javadoc{% endtrans %} -

    +

    {% trans %}Family Options{% endtrans %}

    + +

    Note: Preliminary, subject to change.

    + +

    {% trans -%} +As of release 0.9.24, routers may declare that they are part of a "family", operated by the same entity. +Multiple routers in the same family will not be used in a single tunnel. +{%- endtrans %}

    + +

    {% trans -%} +The family options are: +{%- endtrans %}

    + +
      +
    • family +({% trans %}The family name{% endtrans %}) +
      • +
    • family.key +The type code of the family's +Signing Public Key +(in ASCII digits) +concatenated with ':' +concatenated with the Signing Public Key in base 64 +
      • +
    • family.sig +The signature of ((family name in UTF-8) concatenated with (32 byte router hash)) in base 64 +
      • +
    +

    {% trans %}RouterInfo Expiration{% endtrans %}

    {% trans -%} @@ -156,6 +182,15 @@ RouterInfos are periodically written to disk so that they are available after a {%- endtrans %}

    +

    {% trans %}See Also{% endtrans %}

    + +

    + {% trans %}RouterInfo specification{% endtrans %} +

    +

    + {% trans %}RouterInfo Javadoc{% endtrans %} +

    +

    LeaseSet

    {% trans -%} From c7f299da549dd9b4a7d1a725dc6f9c74747b45b7 Mon Sep 17 00:00:00 2001 From: dev Date: Tue, 12 Jan 2016 17:45:18 +0000 Subject: [PATCH 072/114] Added initial reseeed page. --- i2p2www/pages/site/docs/reseed.html | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 i2p2www/pages/site/docs/reseed.html diff --git a/i2p2www/pages/site/docs/reseed.html b/i2p2www/pages/site/docs/reseed.html new file mode 100644 index 00000000..97daa3bc --- /dev/null +++ b/i2p2www/pages/site/docs/reseed.html @@ -0,0 +1,15 @@ +{% extends "global/layout.html" %} +{% block title %}{% trans %}Reseed Services{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.23{% endblock %} +{% block content %} + +

    {% trans -%} +Reseed hosts are needed to for bootstrapping, that is providing the initial set of I2P nodes for your I2P node to talk to. Depending on the status of your node it may need to bootstrap every now and then if many of the nodes it knows of aren't contactable. +{%- endtrans %}

    + +

    {% trans -%} +Reseeding is done over an encrypted connection and all of the bootstrap information is signed by the reseed host you connect to, making it impossible for an unauthenticated source to provide you with false information. +{%- endtrans %}

    + +{% endblock %} From 1946a667223f542e7235f67b2bc6ab19929eeef3 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 12 Jan 2016 23:03:32 +0000 Subject: [PATCH 073/114] formatting --- i2p2www/pages/site/docs/how/elgamal-aes.html | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/i2p2www/pages/site/docs/how/elgamal-aes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html index 571b07ad..e1bb884b 100644 --- a/i2p2www/pages/site/docs/how/elgamal-aes.html +++ b/i2p2www/pages/site/docs/how/elgamal-aes.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}ElGamal/AES + SessionTag Encryption{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}March 2014{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.12{% endblock %} +{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %}

    {% trans %}Overview{% endtrans %}

    {% trans -%} @@ -180,7 +180,8 @@ and the encrypted block is 514 bytes long.

    {% trans -%} The unencrypted data in the AES block contains the following: {%- endtrans %}

    -
    +
+{% highlight lang='dataspec' %}
    +----+----+----+----+----+----+----+----+
    |tag count|                             |
    +----+----+                             +
@@ -220,7 +221,10 @@ The unencrypted data in the AES block contains the following:
    +----+----+----//---+----+              +
    |          Padding to 16 bytes          |
    +----+----+----+----+----+----+----+----+
+{% endhighlight %}
 
+
    Definition
    
+{% highlight lang='dataspec' %}
 tag count: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
 2-byte Integer, 0-200
 {%- endtrans %}
@@ -252,10 +256,10 @@ Padding: {% trans -%}
 Random data to a multiple of 16 bytes for the total length.
          May contain more than the minimum required padding.
 {%- endtrans %}
+{% endhighlight %}
 
 {% trans %}Minimum length: 48 bytes{% endtrans %}
 
-

    {% trans cryptography=site_url('docs/how/cryptography') -%} The data is then AES Encrypted, @@ -287,7 +291,8 @@ ElGamal block. The existing session message is as follows: {%- endtrans %}

    -
    +
+{% highlight lang='dataspec' %}
    +----+----+----+----+----+----+----+----+
    |                                       |
    +                                       +
@@ -305,15 +310,18 @@ as follows:
    +                                       +
    |                                       |
    +----+----+----+----+----+----+----+----+
+{% endhighlight %}
 
+
    Definition
    
+{% highlight lang='dataspec' %}
 Session Tag: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
 A 32-byte Session Tag
              previously delivered in an AES block
 {%- endtrans %}
 
 AES Encrypyted Block: {% trans %}As specified above.{% endtrans %}
+{% endhighlight %}
 
-

    {% trans -%} The session tag also serves as From aae070a708f7e4a169df9f49f8100df78c73cc91 Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 13 Jan 2016 13:11:15 +0000 Subject: [PATCH 074/114] fixup --- i2p2www/pages/site/docs/how/elgamal-aes.html | 24 ++++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/site/docs/how/elgamal-aes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html index e1bb884b..13b6b52d 100644 --- a/i2p2www/pages/site/docs/how/elgamal-aes.html +++ b/i2p2www/pages/site/docs/how/elgamal-aes.html @@ -225,28 +225,28 @@ The unencrypted data in the AES block contains the following:

    Definition

    {% highlight lang='dataspec' %} -tag count: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -2-byte Integer, 0-200 +tag count: +2-byte `Integer`, 0-200 {%- endtrans %} -Session Tags: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -That many 32-byte Session Tags +Session Tags: +That many 32-byte `SessionTag`s {%- endtrans %} -payload size: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -4-byte Integer +payload size: +4-byte `Integer` {%- endtrans %} -Payload Hash: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -The 32-byte SHA256 Hash of the payload +Payload Hash: +The 32-byte SHA256 `Hash` of the payload {%- endtrans %} flag: {% trans -%} A one-byte value. Normally == 0. If == 0x01, a Session Key follows {%- endtrans %} -New Session Key: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -A 32-byte Session Key, +New Session Key: +A 32-byte `SessionKey`, to replace the old key, and is only present if preceding flag is 0x01 {%- endtrans %} @@ -314,8 +314,8 @@ as follows:

    Definition

    {% highlight lang='dataspec' %} -Session Tag: {% trans commonstructures=site_url('docs/spec/common-structures') -%} -A 32-byte Session Tag +Session Tag: +A 32-byte `SessionTag` previously delivered in an AES block {%- endtrans %} From 88a3db6d047abc59aaed06bbb432fef609cc8fa8 Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 13 Jan 2016 15:51:59 +0000 Subject: [PATCH 075/114] fixup 2 --- i2p2www/pages/site/docs/how/elgamal-aes.html | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/site/docs/how/elgamal-aes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html index 13b6b52d..70ae9b72 100644 --- a/i2p2www/pages/site/docs/how/elgamal-aes.html +++ b/i2p2www/pages/site/docs/how/elgamal-aes.html @@ -227,35 +227,28 @@ The unencrypted data in the AES block contains the following: {% highlight lang='dataspec' %} tag count: 2-byte `Integer`, 0-200 -{%- endtrans %} Session Tags: That many 32-byte `SessionTag`s -{%- endtrans %} payload size: 4-byte `Integer` -{%- endtrans %} Payload Hash: The 32-byte SHA256 `Hash` of the payload -{%- endtrans %} -flag: {% trans -%} +flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows -{%- endtrans %} New Session Key: A 32-byte `SessionKey`, to replace the old key, and is only present if preceding flag is 0x01 -{%- endtrans %} -Payload: {% trans %}the data{% endtrans %} +Payload: the data -Padding: {% trans -%} +Padding: Random data to a multiple of 16 bytes for the total length. May contain more than the minimum required padding. -{%- endtrans %} {% endhighlight %} {% trans %}Minimum length: 48 bytes{% endtrans %} @@ -317,9 +310,8 @@ as follows: Session Tag: A 32-byte `SessionTag` previously delivered in an AES block -{%- endtrans %} -AES Encrypyted Block: {% trans %}As specified above.{% endtrans %} +AES Encrypyted Block: As specified above. {% endhighlight %} From 88904d6408f777a1bb29a1b336aeb2d74ebee85d Mon Sep 17 00:00:00 2001 From: zzz Date: Thu, 14 Jan 2016 14:10:12 +0000 Subject: [PATCH 076/114] More I2PTunnel HTTP and IRC client docs --- i2p2www/pages/site/docs/api/i2ptunnel.html | 64 +++++++++++++++------- 1 file changed, 44 insertions(+), 20 deletions(-) diff --git a/i2p2www/pages/site/docs/api/i2ptunnel.html b/i2p2www/pages/site/docs/api/i2ptunnel.html index 1fb845fc..1b1eee3c 100644 --- a/i2p2www/pages/site/docs/api/i2ptunnel.html +++ b/i2p2www/pages/site/docs/api/i2ptunnel.html @@ -1,12 +1,8 @@ {% extends "global/layout.html" %} {% block title %}I2PTunnel{% endblock %} +{% block lastupdated %}January 2016{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %} -

    {% trans %}Overview{% endtrans %}

    {% trans naming=site_url('docs/naming') -%} @@ -69,20 +65,28 @@ in a HTTP request. Supports proxying onto internet if an outproxy is provided. S {%- endtrans %}

    • {% trans -%} -Accept, Accept-Charset, Accept-Encoding, Accept-Language +Accept, Accept-Charset, Accept-Language and Accept-Ranges as they vary greatly between browsers and can be used as an identifier. {%- endtrans %}
    • Referer:
    • Via:
    • From:
    -

    {% trans -%} -HTTP client/server tunnels are via I2Ptunnel force-enabling compression via the following http headers: -{%- endtrans %}

    + +

    +The i2ptunnel compression is requested with the HTTP header: +

      -
    • Accept-Encoding:
    • X-Accept-Encoding: x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0
    + +

    +The response indicating i2ptunnel compression contains the following HTTP header: +

    +
      +
    • Content-Encoding: x-i2p-gzip
      • +
    +

    {% trans -%} Depending on if the tunnel is using an outproxy or not it will append the following User-Agent: {%- endtrans %}

    @@ -92,23 +96,43 @@ Depending on if the tunnel is using an outproxy or not it will append the follow

    -

    IRC

    +

    IRC Client

    {% trans -%} Creates a connection to a random IRC server specified by the comma seprated (", ") list of destinations. Only a whitelisted subset of IRC commands are allowed due to anonymity concerns. {%- endtrans %} +The following whitelist is for commands inbound from the IRC server to the IRC client.
    {% trans %}Whitelist:{% endtrans %}

      -
    • MODE
      • -
    • JOIN
      • -
    • NICK
      • -
    • QUIT
      • -
    • PART
      • -
    • WALLOPS
      • +
    • AUTHENTICATE
      • +
    • CAP
    • ERROR
      • -
    • KICK
    • H
      • +
    • JOIN
      • +
    • KICK
      • +
    • MODE
      • +
    • NICK
      • +
    • PART
      • +
    • PING
      • +
    • PROTOCTL
      • +
    • QUIT
    • TOPIC
      • +
    • WALLOPS
      • +
    + +

    +There is also a whitelist is for commands outbound from the IRC client to the IRC server. +It is quite large due to the number of IRC administrative commands. +See the IRCFilter.java source for details. +The outbound filter also modifies the following commands to strip identifying information: +

    +
      +
    • NOTICE
      • +
    • PART
      • +
    • PING
      • +
    • PRIVMSG
      • +
    • QUIT
      • +
    • USER

    SOCKS 4/4a/5

    @@ -156,7 +180,7 @@ capabilities. An example application would be a web application that does client requests, or loopback-testing an eepsite as a diagnostic tool. {%- endtrans %}

    -

    IRC

    +

    IRC Server

    {% trans -%} Creates a destination that filters the reqistration sequence of a client and passes the clients destination key as a hostname to the IRC-server. From 721a1ea0100d538c2d7336b18c5381064f16fbd0 Mon Sep 17 00:00:00 2001 From: dev Date: Mon, 18 Jan 2016 21:25:06 +0000 Subject: [PATCH 077/114] Added information about the AdvancedSettings method in i2pcontrol. --- i2p2www/pages/site/docs/api/i2pcontrol.html | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/i2p2www/pages/site/docs/api/i2pcontrol.html b/i2p2www/pages/site/docs/api/i2pcontrol.html index cd55395f..ac9bb1d9 100644 --- a/i2p2www/pages/site/docs/api/i2pcontrol.html +++ b/i2p2www/pages/site/docs/api/i2pcontrol.html @@ -204,6 +204,19 @@ Parameters are only provided in a named way (maps).

  • RestartNeeded – [boolean] {% trans %}Is a restart needed for the new settings to be used.{% endtrans %}
    • +
      AdvancedSettings – {% trans %}Allows for manipulation of advanced i2p settings{% endtrans %} +
        {{ _('Set:') }} – {% trans %}Set the sent key-value pairs{% endtrans %} +
      • {"setting-key": "setting-value", ...} – [Map]
        • +
      +
        {{ _('SetAll:') }} – {% trans %}Set the sent key-value pairs, remove everything else{% endtrans %} +
      • {"setting-key": "setting-value", ...} – [Map]
        • +
      +
        {{ _('Get:') }} – {% trans %}Set the sent key-value pairs, remove everything else{% endtrans %} +
      • "setting-key" – [String]
        • +
      +
        {{ _('GetAall:') }} +
      +

    * {% trans %}denotes an optional value.{% endtrans %}

    ** {% trans %}denotes a possibly occuring return value{% endtrans %}

    From b3cc5a252e6ccb0ea000e2068c586b85cfdb7b64 Mon Sep 17 00:00:00 2001 From: lazygravy Date: Sat, 23 Jan 2016 21:50:27 +0000 Subject: [PATCH 078/114] Fixing link to list of release posts. --- i2p2www/pages/downloads/list.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index dfe7a392..d0c1b7dc 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -41,7 +41,7 @@ or type java -version at your command prompt.

    {{ _('Release Notes') }}

    • -{{ _('Release Notes') }} +{{ _('Release Notes') }}
    • {{ _('Change Log') }}
    • From 53a35baaaa0782403ccdb0b793f96a3493be6142 Mon Sep 17 00:00:00 2001 From: lazygravy Date: Sat, 23 Jan 2016 22:19:39 +0000 Subject: [PATCH 079/114] Adding 32C3 post. --- i2p2www/blog/2016/01/23/32C3.draft.rst | 106 +++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 i2p2www/blog/2016/01/23/32C3.draft.rst diff --git a/i2p2www/blog/2016/01/23/32C3.draft.rst b/i2p2www/blog/2016/01/23/32C3.draft.rst new file mode 100644 index 00000000..66e2f156 --- /dev/null +++ b/i2p2www/blog/2016/01/23/32C3.draft.rst @@ -0,0 +1,106 @@ +{% trans -%} +============== +CCC Recap +============== +{%- endtrans %} +.. meta:: + :author: lazygravy + :date: 2016-01-23 + :category: ccc + :excerpt: {% trans %}CCC!{% endtrans %} + +{% trans -%} +Attending: Sadie, Colin, lazygravy, zzz, hottuna, kytv, cacapo, and eche|on. +{%- endtrans %} + +{% trans -%} +Start +===== +Wooo! Another successful year at CCC. +A huge shoutout to the angels and organizers at `32C3`_. +Just like previous years, we were located in Noisy Square to the right of the EFF's table. +Many were able to attend due to the generous donations. +As always, there was a lot of interest in I2P, and we were able to talk to many people who we otherwise would not have had the ability to. +{%- endtrans %} + +.. _{% trans %}`32C3`{% endtrans %}: https://events.ccc.de/congress/2015/wiki/Static:Main_Page + +{% trans -%} +The Year of Usability! +====================== +{%- endtrans %} + +{% trans -%} +There was a lot of talk about the usability of the router console. +Many people noted that their best experience with I2P was through Vuze/I2PBote-Android. +Currently there are vague discussions of redoing the current router console since it is a bit abrasive for new users to understand. +{%- endtrans %} + +{% trans -%} +We need your feedback! +Even if you don't use I2P often, we want to know what you think. +There are lots of ways to contact us, Twitter, or email. +See the `contacts page`_. +{%- endtrans %} + +.. _{% trans %}`contacts page`{% endtrans %}: {{ site_url() }}contact + +{% trans -%} +Reseed Status +============= +{%- endtrans %} + +Let's get more reseeds! +There was a lot of discussion around the current status of the reseed network right now. +As always, more reseed operators are needed! +If you don't know, a reseed server is the server new routers contact to find peers. +If you have the resources to run a reseed, (or if you're talented in Go) email backup -at- i2pmail.i2p. + +{% trans -%} +Sybil Detection (beta) +====================== +{%- endtrans %} + +{% trans -%} +Due to the decentralized nature of I2P, detecting Sybil attacks is not as straight forward as on other networks (i.e. tor). +To Mitigate this, zzz has been working on a new router-based Sybil detection tool. +To be brief, the tool runs in the router, and collects information on floodfills your router is using. +Right now, the tool is mainly collecting a baseline, and does not act on any of the information it is collecting. +Expect to see a writeup on this more as 0.9.25 or 0.9.26 approaches, as it is still in active development! +{%- endtrans %} + +{% trans -%} +Development Meeting +=================== +{%- endtrans %} + +{% trans -%} +On the 30th we held an in person `meeting`_ at our table. +The meeting focused on organizationally preparing for more project management, and public relations (both from Sadie). +{%- endtrans %} + +.. _{% trans %}`meeting`{% endtrans %}: {{ site_url() }}meetings/241 + +{% trans -%} +We discussed how much of the awesome work done on I2P is lost in the commits. +Meaning that to non-developers, there is nothing to see. +To remedy this lazygravy plans on preparing a series of technical posts explaining some technical topics in I2P. +For example, but not limited to, encrypted lease sets, why different tunnel types are needed, some observations seen in [i2spy](GITHUB LINK). +{%- endtrans %} + +{% trans -%} +Meeting (Future) +================ +{%- endtrans %} + +{% trans -%} +There will be a `another meeting`_ on 2 Feburary 2016 to discuss... +{%- endtrans %} + +- {% trans -%}Review of assigned tasks from 30 December meeting{% endtrans %} +- {% trans -%}Project meeting plan for 2016{% endtrans %} +- {% trans -%}GMP 6 readiness{% endtrans %} +- {% trans -%}A proposal for a code of conduct{% endtrans %} + +.. _{% trans %}`another meeting`{% endtrans %}: http://zzz.i2p/topics/2014-meeting-tues-feb-2-8-pm-utc + From 32dce37d3967834d3db7e566e8a4cb459454d0de Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 23 Jan 2016 23:55:59 +0000 Subject: [PATCH 080/114] fix header --- i2p2www/blog/2016/01/23/32C3.draft.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/blog/2016/01/23/32C3.draft.rst b/i2p2www/blog/2016/01/23/32C3.draft.rst index 66e2f156..5898a257 100644 --- a/i2p2www/blog/2016/01/23/32C3.draft.rst +++ b/i2p2www/blog/2016/01/23/32C3.draft.rst @@ -1,7 +1,7 @@ {% trans -%} -============== +========= CCC Recap -============== +========= {%- endtrans %} .. meta:: :author: lazygravy From f881305fe628a2ba1d952fb1c981317c8fd555f4 Mon Sep 17 00:00:00 2001 From: lazygravy Date: Sun, 24 Jan 2016 03:12:09 +0000 Subject: [PATCH 081/114] Javadocs now use i2p-javadocs.i2p for in-network, and docs.i2p-projekt.de for clearnet. --- i2p2www/pages/site/docs/api/datagrams.html | 8 ++--- .../pages/site/docs/api/ministreaming.html | 4 +-- i2p2www/pages/site/docs/api/sam.html | 2 +- i2p2www/pages/site/docs/api/samv2.html | 2 +- i2p2www/pages/site/docs/api/samv3.html | 8 ++--- i2p2www/pages/site/docs/api/streaming.html | 14 ++++---- .../site/docs/applications/embedding.html | 2 +- .../pages/site/docs/how/network-database.html | 6 ++-- .../pages/site/docs/how/peer-selection.html | 4 +-- i2p2www/pages/site/docs/index.html | 18 +++++----- i2p2www/pages/site/docs/naming.html | 2 +- i2p2www/pages/site/docs/protocol/i2cp.html | 2 +- i2p2www/pages/site/docs/protocol/i2np.html | 2 +- .../site/docs/spec/common-structures.html | 36 +++++++++---------- .../pages/site/docs/spec/configuration.html | 2 +- i2p2www/pages/site/docs/spec/i2cp.html | 4 +-- .../pages/site/docs/spec/tunnel-message.html | 2 +- i2p2www/pages/site/misc/jbigi.html | 2 +- i2p2www/templatevars.py | 1 + 19 files changed, 61 insertions(+), 60 deletions(-) diff --git a/i2p2www/pages/site/docs/api/datagrams.html b/i2p2www/pages/site/docs/api/datagrams.html index 0d6cfd7e..d70949d7 100644 --- a/i2p2www/pages/site/docs/api/datagrams.html +++ b/i2p2www/pages/site/docs/api/datagrams.html @@ -23,7 +23,7 @@ either protocol may be carried by either transport. {%- endtrans %}

      {% trans %}Application Guide{% endtrans %}

      -

      {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/datagram/package-summary.html', +

      {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/datagram/package-summary.html', sam= site_url('docs/api/sam'), socks=site_url('docs/api/socks') -%} Applications written in Java may use the @@ -70,7 +70,7 @@ Applications may add 'from' and 'to' ports to the I2CP (gzip) header as describe the I2CP page. {%- endtrans %}

      -

      {% trans i2psession='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html' -%} +

      {% trans i2psession='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/I2PSession.html' -%} There is no method within the datagram API to specify whether it is non-repliable (raw) or repliable. The application should be designed to expect the appropriate type. The I2CP protocol number or port should be used by the application to @@ -82,8 +82,8 @@ use signed datagrams for a request which includes a nonce, and use a raw datagra for the reply, returning the nonce from the request. {%- endtrans %}

      -

      {% trans i2psession='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html', -i2psessionmuxed='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSessionMuxedImpl.html' -%} +

      {% trans i2psession='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/I2PSession.html', +i2psessionmuxed='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/I2PSessionMuxedImpl.html' -%} The protocols and ports may be set in I2CP's I2PSession API, as implemented in diff --git a/i2p2www/pages/site/docs/api/ministreaming.html b/i2p2www/pages/site/docs/api/ministreaming.html index 82b91d80..0061ba1a 100644 --- a/i2p2www/pages/site/docs/api/ministreaming.html +++ b/i2p2www/pages/site/docs/api/ministreaming.html @@ -4,7 +4,7 @@

      {% trans %}Note{% endtrans %}

      -

      {% trans streaming=site_url('docs/api/streaming'), api='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html' -%} +

      {% trans streaming=site_url('docs/api/streaming'), api='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/package-summary.html' -%} The ministreaming library has been enhanced and extended by the "full" streaming library. Ministreaming is deprecated and is incompatible with today's applications. @@ -42,7 +42,7 @@ messages sent (or include any application level ACK or SACK), so it must wait on average twice the time it takes to send a message before sending another. {%- endtrans %}

      -

      {% trans api='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html', +

      {% trans api='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/package-summary.html', samv3=site_url('docs/api/samv3') -%} Even with those issues, the ministreaming library performs quite well in many situations, and its API diff --git a/i2p2www/pages/site/docs/api/sam.html b/i2p2www/pages/site/docs/api/sam.html index 74f377e1..b81d1df7 100644 --- a/i2p2www/pages/site/docs/api/sam.html +++ b/i2p2www/pages/site/docs/api/sam.html @@ -389,7 +389,7 @@ followed by the Signing Private Key, which is 884 or more base 64 characters (663 or more bytes in binary), depending on signature type. -The binary format is specified in Private Key File. +The binary format is specified in Private Key File. ---------------------------------------------------------------------- RESULT values diff --git a/i2p2www/pages/site/docs/api/samv2.html b/i2p2www/pages/site/docs/api/samv2.html index d7104aac..6f2d11db 100644 --- a/i2p2www/pages/site/docs/api/samv2.html +++ b/i2p2www/pages/site/docs/api/samv2.html @@ -446,7 +446,7 @@ followed by the Signing Private Key, which is 884 or more base 64 characters (663 or more bytes in binary), depending on signature type. -The binary format is specified in Private Key File. +The binary format is specified in Private Key File. ---------------------------------------------------------------------- RESULT values diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 9bd80608..4384ba52 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -342,7 +342,7 @@ followed by the Signing Private Key, which is 663 or more bytes in binary and 884 or more bytes in base 64, depending on signature type. -The binary format is specified in Private Key File. +The binary format is specified in Private Key File.

      If the destination is specified as TRANSIENT, the SAM bridge creates a new destination. @@ -384,7 +384,7 @@ followed by the Signing Private Key, which is 663 or more bytes in binary and 884 or more bytes in base 64, depending on signature type. -The binary format is specified in Private Key File. +The binary format is specified in Private Key File.

      If the nickname is already associated with a session: @@ -808,7 +808,7 @@ CREATE command with PORT and HOST options: followed by the Signing Private Key, which is 884 or more base 64 characters (663 or more bytes in binary), depending on signature type. - The binary format is specified in Private Key File. + The binary format is specified in Private Key File.

      $host is the hostname or IP address of the datagram server to @@ -1033,7 +1033,7 @@ followed by the Signing Private Key, which is 884 or more base 64 characters (663 or more bytes in binary), depending on signature type. -The binary format is specified in Private Key File. +The binary format is specified in Private Key File.

      PING/PONG (SAM 3.2 or higher)

      diff --git a/i2p2www/pages/site/docs/api/streaming.html b/i2p2www/pages/site/docs/api/streaming.html index 7db00de1..39699b09 100644 --- a/i2p2www/pages/site/docs/api/streaming.html +++ b/i2p2www/pages/site/docs/api/streaming.html @@ -65,11 +65,11 @@ streaming library, to be interpreted by I2CP. {%- endtrans %}

      {% trans i2cp=site_url('docs/protocol/i2cp'), -i2psktmf='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html', -i2psktm='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManager.html', -i2psess='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html', -i2pskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocket.html', -i2psskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PServerSocket.html' -%} +i2psktmf='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/I2PSocketManagerFactory.html', +i2psktm='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/I2PSocketManager.html', +i2psess='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/I2PSession.html', +i2pskt='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/I2PSocket.html', +i2psskt='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/I2PServerSocket.html' -%} The standard interface to the streaming lib is for the application to use the I2PSocketManagerFactory to create an I2PSocketManager. The application then asks the @@ -79,7 +79,7 @@ can then setup connections with an I2PSocket or receive connections with an I2PServerSocket. {%- endtrans %}

      -

      {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html' -%} +

      {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/package-summary.html' -%} Here are the full streaming library Javadocs. {%- endtrans %}

      @@ -89,7 +89,7 @@ For a good example of usage, see the i2psnark code.

      {% trans %}Options and Defaults{% endtrans %}

      -

      {% trans i2psktmf='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html' -%} +

      {% trans i2psktmf='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/streaming/I2PSocketManagerFactory.html' -%} The options and current default values are listed below. Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a per-connection basis. diff --git a/i2p2www/pages/site/docs/applications/embedding.html b/i2p2www/pages/site/docs/applications/embedding.html index 29553b2b..c62da404 100644 --- a/i2p2www/pages/site/docs/applications/embedding.html +++ b/i2p2www/pages/site/docs/applications/embedding.html @@ -336,7 +336,7 @@ as is done in our Java packages. As always, state management is the difficult part. {%- endtrans %}

      -See also: the Router javadocs. +See also: the Router javadocs.

      {% endblock %} diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index 83d98742..1df1113c 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -188,7 +188,7 @@ RouterInfos are periodically written to disk so that they are available after a {% trans %}RouterInfo specification{% endtrans %}

      - {% trans %}RouterInfo Javadoc{% endtrans %} + {% trans %}RouterInfo Javadoc{% endtrans %}

      LeaseSet

      @@ -224,9 +224,9 @@ In addition to these leases, the LeaseSet includes: {% trans %}LeaseSet specification{% endtrans %}

      - {% trans %}Lease Javadoc{% endtrans %} + {% trans %}Lease Javadoc{% endtrans %}
      - {% trans %}LeaseSet Javadoc{% endtrans %} + {% trans %}LeaseSet Javadoc{% endtrans %}

      diff --git a/i2p2www/pages/site/docs/how/peer-selection.html b/i2p2www/pages/site/docs/how/peer-selection.html index d562e0b8..24022d77 100644 --- a/i2p2www/pages/site/docs/how/peer-selection.html +++ b/i2p2www/pages/site/docs/how/peer-selection.html @@ -63,7 +63,7 @@ See below for notes on minor changes since the paper was pu {%- endtrans %}

      {% trans %}Profiles{% endtrans %}

      -

      {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/PeerProfile.html' -%} +

      {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/router/peermanager/PeerProfile.html' -%} Each peer has a set of data points collected about them, including statistics about how long it takes for them to reply to a network database query, how often their tunnels fail, and how many new peers they are able to introduce @@ -142,7 +142,7 @@ speed calculation meets or exceeds the median of all peers.

    • {% trans %}A peer is considered "standard" if it is not "high capacity"{% endtrans %}
    -

    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html' -%} +

    {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/router/peermanager/ProfileOrganizer.html' -%} These groupings are implemented in the router's ProfileOrganizer. {%- endtrans %}

    diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index 4e534e8e..00c3883a 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -87,11 +87,11 @@ HTTP Bidir Proxy
  • {{ _('Streaming Protocol Specification') }}
  • -{{ _('Streaming Javadoc') }} +{{ _('Streaming Javadoc') }}
  • {{ _('Datagrams') }}
  • -{{ _('Datagram Javadoc') }} +{{ _('Datagram Javadoc') }}

    • {% trans %}Client-to-Router Interface API and Protocol{% endtrans %}

    @@ -104,11 +104,11 @@ Traditionally used only by Java applications and higher-level APIs.
  • {{ _('I2CP Specification') }}
  • -{{ _('I2CP API Javadoc') }} +{{ _('I2CP API Javadoc') }}
  • {{ _('Common data structures specification') }}
  • -{{ _('Data Structures Javadoc') }} +{{ _('Data Structures Javadoc') }}

    • {% trans %}End-to-End Encryption{% endtrans %}

    @@ -134,11 +134,11 @@ Traditionally used only by Java applications and higher-level APIs.
  • {{ _('I2NP Specification') }}
  • -{{ _('I2NP Javadoc') }} +{{ _('I2NP Javadoc') }}
  • {{ _('Common data structures specification') }}
  • -{{ _('Data Structures Javadoc') }} +{{ _('Data Structures Javadoc') }}

    • {% trans %}Tunnels{% endtrans %}

    @@ -172,11 +172,11 @@ Traditionally used only by Java applications and higher-level APIs.
  • {{ _('SSU transport encryption') }}
  • -{{ _('Transport Javadoc') }} +{{ _('Transport Javadoc') }}
  • -{{ _('NTCP Javadoc') }} +{{ _('NTCP Javadoc') }}
  • -{{ _('SSU Javadoc') }} +{{ _('SSU Javadoc') }}

    • {% trans %}Other Router Topics{% endtrans %}

    diff --git a/i2p2www/pages/site/docs/naming.html b/i2p2www/pages/site/docs/naming.html index 4eb3edc0..d11689a6 100644 --- a/i2p2www/pages/site/docs/naming.html +++ b/i2p2www/pages/site/docs/naming.html @@ -140,7 +140,7 @@ It also maintains a reverse-lookup map to implement rapid reverse lookups.

    {{ _('Other Naming Service Facilities') }}

    -

    {% trans nsjavadocs='http://docs.i2p-projekt.de/javadoc/net/i2p/client/naming/package-summary.html' -%} +

    {% trans nsjavadocs='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/naming/package-summary.html' -%} The lookup is case-insensitive. The first match is used, and conflicts are not detected. There is no enforcement of naming rules in lookups. diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html index 6e399a63..e465d4d8 100644 --- a/i2p2www/pages/site/docs/protocol/i2cp.html +++ b/i2p2www/pages/site/docs/protocol/i2cp.html @@ -15,7 +15,7 @@ I2CP to tell the client when any messages have arrived, and to request authoriza for some tunnels to be used. {%- endtrans %}

    -

    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html', +

    {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/client/package-summary.html', libi2cp='http://git.repo.i2p/w/libi2cp.git', streaming=site_url('docs/api/streaming') -%} The protocol itself is implemented in Java, to provide the diff --git a/i2p2www/pages/site/docs/protocol/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html index e2f1d5f8..45783851 100644 --- a/i2p2www/pages/site/docs/protocol/i2np.html +++ b/i2p2www/pages/site/docs/protocol/i2np.html @@ -19,7 +19,7 @@ through multiple hops to the ultimate destination. Priority is only used locally at the origin, i.e. when queuing for outbound delivery. {%- endtrans %}

    -

    {% trans outnetmessage='http://docs.i2p-projekt.de/javadoc/net/i2p/router/OutNetMessage.html' -%} +

    {% trans outnetmessage='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/router/OutNetMessage.html' -%} The priorities listed below may not be current and are subject to change. See the OutNetMessage Javadocs for the current priority settings. diff --git a/i2p2www/pages/site/docs/spec/common-structures.html b/i2p2www/pages/site/docs/spec/common-structures.html index 02711eb5..e886a557 100644 --- a/i2p2www/pages/site/docs/spec/common-structures.html +++ b/i2p2www/pages/site/docs/spec/common-structures.html @@ -98,7 +98,7 @@ This structure is used in ElGamal encryption, representing only the exponent, no 256 bytes {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    PrivateKey

    {% trans %}Description{% endtrans %}

    @@ -111,7 +111,7 @@ This structure is used in ElGamal decryption, representing only the exponent, no 256 bytes {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    SessionKey

    {% trans %}Description{% endtrans %}

    @@ -123,7 +123,7 @@ This structure is used for AES256 encryption and decryption. 32 bytes {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    SigningPublicKey

    @@ -166,7 +166,7 @@ EdDSA, which is stored and transmitted in a Little Endian format. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    SigningPrivateKey

    @@ -209,7 +209,7 @@ EdDSA, which is stored and transmitted in a Little Endian format. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    Signature

    @@ -252,7 +252,7 @@ EdDSA, which is stored and transmitted in a Little Endian format. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    Hash

    @@ -265,7 +265,7 @@ Represents the SHA256 of some data. 32 bytes {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    Session Tag

    {% trans %}Description{% endtrans %}

    @@ -277,7 +277,7 @@ A random number 32 bytes {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    TunnelId

    {% trans %}Description{% endtrans %}

    @@ -292,7 +292,7 @@ A Tunnel ID is generally greater than zero; do not use a value of zero except in 4 byte Integer {% endtrans %}

    -

    Javadoc

    +

    Javadoc

    Certificate

    {% trans %}Description{% endtrans %}

    @@ -456,7 +456,7 @@ Example layouts using an ElGamal Crypto Public Key and the Signing Public Key ty -

    Javadoc

    +

    Javadoc

    Mapping

    @@ -541,7 +541,7 @@ Total length limit is 65535 bytes, plus the 2 byte size field, or 65537 total. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    @@ -609,7 +609,7 @@ The Crypto Public Key is aligned at the start and the Signing Public Key is alig The padding (if any) is in the middle. -

    Javadoc

    +

    Javadoc

    RouterIdentity

    {% trans %}Description{% endtrans %}

    @@ -635,7 +635,7 @@ The Crypto Public Key is aligned at the start and the Signing Public Key is alig The padding (if any) is in the middle. -

    Javadoc

    +

    Javadoc

    Destination

    {% trans %}Description{% endtrans %}

    @@ -664,7 +664,7 @@ The Crypto Public Key is aligned at the start and the Signing Public Key is alig The padding (if any) is in the middle. -

    Javadoc

    +

    Javadoc

    Lease

    {% trans %}Description{% endtrans %}

    @@ -709,7 +709,7 @@ Total size: 44 bytes -

    Javadoc

    +

    Javadoc

    LeaseSet

    {% trans %}Description{% endtrans %}

    @@ -837,7 +837,7 @@ This is an implementation detail and not part of the structures specification. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    @@ -906,7 +906,7 @@ The following options, while not required, are standard and expected to be prese -

    Javadoc

    +

    Javadoc

    RouterInfo

    {% trans %}Description{% endtrans %}

    @@ -1005,7 +1005,7 @@ for standard options that are expected to be present in all router infos. {%- endtrans %} -

    Javadoc

    +

    Javadoc

    Delivery Instructions

    diff --git a/i2p2www/pages/site/docs/spec/configuration.html b/i2p2www/pages/site/docs/spec/configuration.html index d1f8273d..902c8da6 100644 --- a/i2p2www/pages/site/docs/spec/configuration.html +++ b/i2p2www/pages/site/docs/spec/configuration.html @@ -36,7 +36,7 @@ The file need not be sorted, but most applications do sort by key when writing to the file, for ease of reading and manual editing. {%- endtrans %}

    -

    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/data/DataHelper.html', +

    {% trans url='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/data/DataHelper.html', commonstructures=site_url('docs/spec/common-structures') -%} Reads and writes are implemented in DataHelper loadProps() and storeProps(). diff --git a/i2p2www/pages/site/docs/spec/i2cp.html b/i2p2www/pages/site/docs/spec/i2cp.html index 095d8c2e..deab2c2f 100644 --- a/i2p2www/pages/site/docs/spec/i2cp.html +++ b/i2p2www/pages/site/docs/spec/i2cp.html @@ -415,7 +415,7 @@ time.

    Messages

    See also the -I2CP Javadocs. +I2CP Javadocs.

    Message Types

    + +
    MessageDirectionTypeSince @@ -976,7 +976,7 @@ router implementation uses the guaranteed status codes, not the best effort code As of router version 0.9.5, additional status codes are defined, however they are not necessarily implemented. See the -MessageStatusMessage Javadocs +MessageStatusMessage Javadocs for details. All status codes: diff --git a/i2p2www/pages/site/docs/spec/tunnel-message.html b/i2p2www/pages/site/docs/spec/tunnel-message.html index b48956f5..4f4e00c9 100644 --- a/i2p2www/pages/site/docs/spec/tunnel-message.html +++ b/i2p2www/pages/site/docs/spec/tunnel-message.html @@ -287,7 +287,7 @@ size :: total length: 7 bytes {% endhighlight %} -

    Delivery Instructions Javadoc

    +

    Delivery Instructions Javadoc

    Notes

    I2NP Message Maximum Size

    diff --git a/i2p2www/pages/site/misc/jbigi.html b/i2p2www/pages/site/misc/jbigi.html index 48769133..e09b5c89 100644 --- a/i2p2www/pages/site/misc/jbigi.html +++ b/i2p2www/pages/site/misc/jbigi.html @@ -22,7 +22,7 @@ as a replacement for the As modPow() is a significant computational portion of many crypto operations, this is of significant benefit. {%- endtrans %}

    -

    {% trans nativebigint='http://docs.i2p-projekt.de/javadoc/net/i2p/util/NativeBigInteger.html', +

    {% trans nativebigint='http://'+i2pconv('i2p-javadocs.i2p')+'/net/i2p/util/NativeBigInteger.html', bigint='http://download.oracle.com/javase/1.5.0/docs/api/java/math/BigInteger.html#modPow%28java.math.BigInteger,%20java.math.BigInteger%29' -%} The standard I2P installation includes about 20 versions of the library for different platforms, each about 50KB, inside the jbigi.jar file. diff --git a/i2p2www/templatevars.py b/i2p2www/templatevars.py index b9742939..975e4a9e 100644 --- a/i2p2www/templatevars.py +++ b/i2p2www/templatevars.py @@ -10,6 +10,7 @@ I2P_TO_CLEAR = { 'trac.i2p2.i2p': 'trac.i2p2.de', 'mail.i2p': 'i2pmail.org', 'lists.i2p2.i2p': 'lists.i2p2.de', + 'i2p-javadocs.i2p': 'docs.i2p-projekt.de/javadoc', # Hacky to include the path, but it works! 'stats.i2p': 'stats.i2p', # Inproxy disabled at request of site owner 'zzz.i2p': 'zzz.i2p', # Inproxy disabled at request of site owner } From bf473630d3c9d3f3a1830c7966efc7cc3996a293 Mon Sep 17 00:00:00 2001 From: dev Date: Sun, 24 Jan 2016 17:38:13 +0000 Subject: [PATCH 082/114] Added reseed doc to menu, About->Documentaion->Reseed. --- i2p2www/pages/global/nav.html | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 6818e764..e50374ae 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -86,6 +86,7 @@

  • {{ _('Naming and addressbook') }}
  • {{ _('Plugins') }}
    • +
  • {{ _('Reseed') }}
  • {{ _('Team') }}
    • From 35db787774dd56f053585ab2ff6e082aed1bac7b Mon Sep 17 00:00:00 2001 From: lazygravy Date: Sun, 24 Jan 2016 18:09:45 +0000 Subject: [PATCH 083/114] Switch sam.pm license to GPL, which is what the code states. Use https for Wikipedia links. --- .../site/get-involved/develop/licenses.html | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/i2p2www/pages/site/get-involved/develop/licenses.html b/i2p2www/pages/site/get-involved/develop/licenses.html index 3f97a277..a3b3fae0 100644 --- a/i2p2www/pages/site/get-involved/develop/licenses.html +++ b/i2p2www/pages/site/get-involved/develop/licenses.html @@ -65,7 +65,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain + Public domain @@ -101,7 +101,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain @@ -126,7 +126,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain @@ -138,7 +138,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib @@ -176,7 +176,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + WTFPL @@ -186,7 +186,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain + GPL @@ -215,7 +215,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib @@ -226,9 +226,9 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain @@ -239,9 +239,9 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain @@ -251,8 +251,8 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib @@ -263,7 +263,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib + Public domain + +
    core i2p.jar - Public domain BSD
    Cryptix
    @@ -77,7 +77,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib     		router router.jar - Public domain BSD
    Cryptix
    @@ -91,7 +91,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib     		BSD - Public domain
    + Public domain
    Cryptix
    MIT    		 zzzapps/streaming streaming.jar - Public domain BSD
    Cryptix
    @@ -115,7 +115,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib     		GPL + exception - Public domain
    + Public domain
    BSD
    Cryptix
    MIT    		apps/routerconsole routerconsole.war - Public domain   zzz
    MIT - Public domain
    + Public domain
    Cryptix
    BSD    		  BOB.jar - WTFPL   sponge
    sam.jar - Public domain Cryptix
    BSD
    @@ -199,9 +199,9 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib     		SAM.pm - Artistic - Public domain
    + Public domain
    Cryptix
    BSD
    MIT    		 BSD - Public domain
    + Public domain
    Cryptix
    MIT    		 Nightbladei2p.py - Public domain - BSD
    + BSD
    Cryptix
    MIT    		 Connellyn/a - Public domain - BSD
    + BSD
    Cryptix
    MIT    		 smegheadapps/ ... - probably - Public domain + Probably + Public domain but check the source    install.jar, guiinstall.jar - Public domain GPL + exception
    BSD
    Cryptix
    From 6bb40ee2810680ebf83dd6de9c19e0446cee7195 Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 27 Jan 2016 18:31:23 +0000 Subject: [PATCH 084/114] 0.9.24 draft --- .../blog/2016/01/27/0.9.24-Release.draft.rst | 113 ++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst diff --git a/i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst b/i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst new file mode 100644 index 00000000..e12598e4 --- /dev/null +++ b/i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst @@ -0,0 +1,113 @@ +{% trans -%} +============== +0.9.24 Release +============== +{%- endtrans %} +.. meta:: + :author: zzz + :date: 2016-01-27 + :category: release + :excerpt: {% trans %}0.9.24 contains a variety of bug fixes and performance enhancements{% endtrans %} + +{% trans -%} +Update details +============== +{%- endtrans %} + +{% trans -%} +0.9.24 contains a new version of SAM (v3.2) and numerous bug fixes and efficiency improvements. +Note that this release is the first to require Java 7. +Please update to Java 7 or 8 as soon as possible. +Your router will not automatically update if you are using Java 6. +{%- endtrans %} + +{% trans -%} +To prevent the problems caused by the ancient commons-logging library, we have removed it. +This will cause very old I2P-Bote plugins (0.2.10 and below, signed by HungryHobo) to crash if they have IMAP enabled. +The recommended fix is to replace your old I2P-Bote plugin with the current one signed by str4d. +For more details, see `this post`_. +{%- endtrans %} + +.. _{% trans %}`this post`{% endtrans %}: http://bote.i2p/news/0.4.3 + +{% trans -%} +We had a great `32C3 Congress`_ and are making good progress on our 2016 project plans. +Echelon gave a talk on I2P's history and current status, and his slides are `available here`_ (pdf). +Str4d attended `Real World Crypto`_ and gave a talk on our crypto migration, his slides are `here`_ (pdf). +{%- endtrans %} + +.. _{% trans %}`32C3 Congress`{% endtrans %}: {{ site_url() }}blog/post/2016/01/23/32C3 + +.. _{% trans %}`available here`{% endtrans %}: https://download.i2p2.de/media/ccc/2015/I2P_Still_alive.pdf + +.. _{% trans %}`Real World Crypto`{% endtrans %}: http://www.realworldcrypto.com/rwc2016/program + +.. _{% trans %}`here`{% endtrans %}: https://download.i2p2.de/media/rwc/2016/rwc2016-str4d-slides.pdf + +{% trans -%} +As usual, we recommend that you update to this release. The best way to +maintain security and help the network is to run the latest release. +{%- endtrans %} + + +**{% trans %}RELEASE DETAILS{% endtrans %}** + +**{% trans %}Changes{% endtrans %}** + +- {% trans %}Java 7 now required{% endtrans %} +- {% trans %}SAM 3.2, with several new advanced features, command parser improvements, and lots of bug fixes{% endtrans %} +- {% trans %}Router Family{% endtrans %} +- {% trans %}Commons logging removed{% endtrans %} + + +**{% trans %}Bug Fixes{% endtrans %}** + +- {% trans %}Fix HTML escaping in the console plugin table{% endtrans %} +- {% trans %}Fix rare deadlocks in the router{% endtrans %} +- {% trans %}Fix the tunnel build Bloom filter{% endtrans %} +- {% trans %}Don't remove tunnel on next-hop failure indication from transport, it isn't reliable{% endtrans %} +- {% trans %}Fix formatting in summary bar to prevent overflow{% endtrans %} +- {% trans %}Fix console links in i2ptunnel error pages when on nonstandard host/port{% endtrans %} +- {% trans %}Don't query floodfills whose version is too old to support encrypted replies{% endtrans %} +- {% trans %}Reduce out-of-order delivery in SSU{% endtrans %} +- {% trans %}Fix a rare NPE in the tunnel build handler{% endtrans %} + + +**{% trans %}Other{% endtrans %}** + +- {% trans %}Listen for Windows Service shutdown events to shutdown cleanly{% endtrans %} +- {% trans %}Fix some IPv6 issues on Windows{% endtrans %} +- {% trans %}Change Jetty request logging from b64 to b32{% endtrans %} +- {% trans %}New 'family' indication in netdb, don't use two of the same family in a tunnel{% endtrans %} +- {% trans %}New overview picture in SusiDNS{% endtrans %} +- {% trans %}Close connection faster if it's for a rejected tunnel request{% endtrans %} +- {% trans %}Use SSU extended options field for session request message{% endtrans %} +- {% trans %}Request introduction in the SSU extended options{% endtrans %} +- {% trans %}Don't offer to introduce unless requested, to introduce only those that need it{% endtrans %} +- {% trans %}Experimental Sybil analysis tool, requires routerconsole.advanced=true{% endtrans %} +- {% trans %}Persist some profile netdb stats that weren't being saved{% endtrans %} +- {% trans %}Memory reduction and other efficiency improvements throughout{% endtrans %} +- {% trans %}Increase several limits in i2psnark{% endtrans %} +- {% trans %}New streaming unit tests{% endtrans %} +- {% trans %}Fix some SSU stats on /peers to be consistent with NTCP{% endtrans %} +- {% trans %}Change default sig type for new i2ptunnels to Ed25519{% endtrans %} +- {% trans %}Increase router rekey probability at startup again{% endtrans %} +- {% trans %}New Chinese (Taiwan) translation{% endtrans %} +- {% trans %}Translation updates{% endtrans %} +- {% trans %}Update GeoIP data (new installs and PPA only){% endtrans %} + + +`Full list of fixed bugs`_ + +.. _{% trans %}`Full list of fixed bugs`{% endtrans %}: http://trac.i2p2.de/query?resolution=fixed&milestone=0.9.24 + + +**{% trans %}SHA256 Checksums:{% endtrans %}** + +:: + + 40a9d162b218c3280170b5e6e5e0f459a2c5348c9488222955be5312144eade9 i2pinstall_0.9.24_windows.exe + f5a06c4ed7e3c22048eef18901b85baa1f9bed3e507c212700723701036e2bb3 i2pinstall_0.9.24.jar + 134481ae5ef934a411545330d1b22e768189c424a65db47058db0f7d9cf51e7d i2psource_0.9.24.tar.bz2 + b8ee5d9c88924f631ae03ffcbed4ac0b06542e51cdd144e20dbaad69a8fdcef4 i2pupdate_0.9.24.zip + 6a3ddb8cb8d24a3b69d1138244c817852d0aa69a1603a3ed05f8368f01497394 i2pupdate.su3 From b5f64e2e6a38e7648cf2bfb6af8c3d1c611451ac Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 27 Jan 2016 18:31:45 +0000 Subject: [PATCH 085/114] undraft 32C3 post --- i2p2www/blog/2016/01/23/{32C3.draft.rst => 32C3.rst} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename i2p2www/blog/2016/01/23/{32C3.draft.rst => 32C3.rst} (100%) diff --git a/i2p2www/blog/2016/01/23/32C3.draft.rst b/i2p2www/blog/2016/01/23/32C3.rst similarity index 100% rename from i2p2www/blog/2016/01/23/32C3.draft.rst rename to i2p2www/blog/2016/01/23/32C3.rst From 8780d7441debf8456d87bc3d489a2261d25963f1 Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 27 Jan 2016 18:32:31 +0000 Subject: [PATCH 086/114] add use cases for each sig type --- .../site/docs/spec/common-structures.html | 112 +++++++++++------- 1 file changed, 72 insertions(+), 40 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/common-structures.html b/i2p2www/pages/site/docs/spec/common-structures.html index e886a557..4d6d2af9 100644 --- a/i2p2www/pages/site/docs/spec/common-structures.html +++ b/i2p2www/pages/site/docs/spec/common-structures.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Common structures Specification{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}April 2015{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.19{% endblock %} +{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content_nav %} @@ -143,15 +143,23 @@ As of release 0.9.12, other types may be supported, depending on context. {% endtrans %}

    {% trans %}Type{% endtrans %}
    - - - - - - - - - + + + + + + + + + + + + + + + + +
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}
    DSA_SHA1128 
    ECDSA_SHA256_P256640.9.12
    ECDSA_SHA384_P384960.9.12
    ECDSA_SHA512_P5211320.9.12
    RSA_SHA256_20482560.9.12
    RSA_SHA384_30723840.9.12
    RSA_SHA512_40965120.9.12
    EdDSA_SHA512_Ed25519320.9.15
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}{% trans %}Usage{% endtrans %}
    DSA_SHA1128 Legacy Router Identities and Destinations
    ECDSA_SHA256_P256640.9.12Recent Destinations
    ECDSA_SHA384_P384960.9.12Rarely used for Destinations
    ECDSA_SHA512_P5211320.9.12Rarely used for Destinations
    RSA_SHA256_20482560.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA384_30723840.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA512_40965120.9.12Offline signing, never used for Router Identities or Destinations
    EdDSA_SHA512_Ed25519320.9.15Recent Router Identities and Destinations

    {% trans %}Notes{% endtrans %}

    @@ -186,15 +194,23 @@ As of release 0.9.12, other types may be supported, depending on context. {% endtrans %}

    - - - - - - - - - + + + + + + + + + + + + + + + + +
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}
    DSA_SHA120 
    ECDSA_SHA256_P256320.9.12
    ECDSA_SHA384_P384480.9.12
    ECDSA_SHA512_P521660.9.12
    RSA_SHA256_20485120.9.12
    RSA_SHA384_30727680.9.12
    RSA_SHA512_409610240.9.12
    EdDSA_SHA512_Ed25519320.9.15
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}{% trans %}Usage{% endtrans %}
    DSA_SHA120 Legacy Router Identities and Destinations
    ECDSA_SHA256_P256320.9.12Recent Destinations
    ECDSA_SHA384_P384480.9.12Rarely used for Destinations
    ECDSA_SHA512_P521660.9.12Rarely used for Destinations
    RSA_SHA256_20485120.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA384_30727680.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA512_409610240.9.12Offline signing, never used for Router Identities or Destinations
    EdDSA_SHA512_Ed25519320.9.15Recent Router Identities and Destinations

    {% trans %}Notes{% endtrans %}

    @@ -229,15 +245,23 @@ As of release 0.9.12, other types may be supported, depending on context. {% endtrans %}

    - - - - - - - - - + + + + + + + + + + + + + + + + +
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}
    DSA_SHA140 
    ECDSA_SHA256_P256640.9.12
    ECDSA_SHA384_P384960.9.12
    ECDSA_SHA512_P5211320.9.12
    RSA_SHA256_20482560.9.12
    RSA_SHA384_30723840.9.12
    RSA_SHA512_40965120.9.12
    EdDSA_SHA512_Ed25519640.9.15
    {% trans %}Type{% endtrans %}{% trans %}Length (bytes){% endtrans %}{% trans %}Since{% endtrans %}{% trans %}Usage{% endtrans %}
    DSA_SHA140 Legacy Router Identities and Destinations
    ECDSA_SHA256_P256640.9.12Recent Destinations
    ECDSA_SHA384_P384960.9.12Rarely used for Destinations
    ECDSA_SHA512_P5211320.9.12Rarely used for Destinations
    RSA_SHA256_20482560.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA384_30723840.9.12Offline signing, never used for Router Identities or Destinations
    RSA_SHA512_40965120.9.12Offline signing, never used for Router Identities or Destinations
    EdDSA_SHA512_Ed25519640.9.15Recent Router Identities and Destinations

    {% trans %}Notes{% endtrans %}

    @@ -372,7 +396,7 @@ As of 0.9.12, a Key Certificate may be used to specify the signing public key ty

    {% trans %}Key Certificates{% endtrans %}

    -Key certificates are preliminary, and are scheduled to be introduced in release 0.9.12. +Key certificates were introduced in release 0.9.12. Prior to that release, all PublicKeys were 256-byte ElGamal keys, and all SigningPublicKeys were 128-byte DSA-SHA1 keys. A key certificate provides a mechanism to indicate the type of the PublicKey and SigningPublicKey @@ -381,7 +405,7 @@ standard lengths.

    By maintaining exactly 384 bytes before the certificate, and putting any excess key data inside the certificate, we maintain compatibility for any software that -parses Destinations and RouterIdentities. +parses Destinations and Router Identities.

    The key certificate payload contains: @@ -400,15 +424,23 @@ The key certificate payload contains:

    The defined Signing Key types are:

    - - - - - - - - - + + + + + + + + + + + + + + + + +
    TypeType CodeTotal Public Key Length{% trans %}Since{% endtrans %}
    DSA_SHA101280.9.12
    ECDSA_SHA256_P2561640.9.12
    ECDSA_SHA384_P3842960.9.12
    ECDSA_SHA512_P52131320.9.12
    RSA_SHA256_204842560.9.12
    RSA_SHA384_307253840.9.12
    RSA_SHA512_409665120.9.12
    EdDSA_SHA512_Ed255197320.9.15
    TypeType CodeTotal Public Key Length{% trans %}Since{% endtrans %}{% trans %}Usage{% endtrans %}
    DSA_SHA101280.9.12Legacy Router Identities and Destinations, never explicitly set
    ECDSA_SHA256_P2561640.9.12Recent Destinations
    ECDSA_SHA384_P3842960.9.12Sometimes used for Destinations
    ECDSA_SHA512_P52131320.9.12Sometimes used for Destinations
    RSA_SHA256_204842560.9.12Offline only; never used in Key Certificates for Router Identities or Destinations
    RSA_SHA384_307253840.9.12Offline only; never used in Key Certificates for Router Identities or Destinations
    RSA_SHA512_409665120.9.12Offline only; never used in Key Certificates for Router Identities or Destinations
    EdDSA_SHA512_Ed255197320.9.15Recent Router Identities and Destinations

    From db354d189996ff656cc2deb9f93ebf383abfbf45 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 29 Jan 2016 18:37:32 +0000 Subject: [PATCH 087/114] 0.9.24 --- i2p2www/__init__.py | 2 +- .../27/{0.9.24-Release.draft.rst => 0.9.24-Release.rst} | 0 i2p2www/pages/downloads/list.html | 2 +- i2p2www/pages/downloads/macros | 8 ++++---- 4 files changed, 6 insertions(+), 6 deletions(-) rename i2p2www/blog/2016/01/27/{0.9.24-Release.draft.rst => 0.9.24-Release.rst} (100%) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 8028d3ba..ce91718f 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -22,7 +22,7 @@ except ImportError: ########### # Constants -CURRENT_I2P_VERSION = '0.9.23' +CURRENT_I2P_VERSION = '0.9.24' CANONICAL_DOMAIN = 'geti2p.net' diff --git a/i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst b/i2p2www/blog/2016/01/27/0.9.24-Release.rst similarity index 100% rename from i2p2www/blog/2016/01/27/0.9.24-Release.draft.rst rename to i2p2www/blog/2016/01/27/0.9.24-Release.rst diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index d0c1b7dc..ddf13732 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {%- from "downloads/macros" import package, package_outer with context -%} -{% set release_signer = 'str4d' %} +{% set release_signer = 'zzz' %} {% block title %}{{ _('Download') }}{% endblock %} {% block content_nav %} diff --git a/i2p2www/pages/downloads/macros b/i2p2www/pages/downloads/macros index 901b3e4e..4c1560d7 100644 --- a/i2p2www/pages/downloads/macros +++ b/i2p2www/pages/downloads/macros @@ -1,7 +1,7 @@ -{% set i2pinstall_windows_hash = '306c0eeb4d0ff210b42cb0a6babe46da59d0f80317451f3fd40381bb79b54852' %} -{% set i2pinstall_jar_hash = '843a8059830b009d10c47cc7c85e260ad88f7c3c16e289bbf80c0eb178318823' %} -{% set i2psource_hash = '24e303f2af1b7b14ed3a6e17cc7d1b6432ec99d8d00246a88486922941c72345' %} -{% set i2pupdate_hash = 'd7f2f2349520071a3d19a4130a83ae1fb109f7924cb1eff5da020678787d3ad3' %} +{% set i2pinstall_windows_hash = '40a9d162b218c3280170b5e6e5e0f459a2c5348c9488222955be5312144eade9' %} +{% set i2pinstall_jar_hash = 'f5a06c4ed7e3c22048eef18901b85baa1f9bed3e507c212700723701036e2bb3' %} +{% set i2psource_hash = '134481ae5ef934a411545330d1b22e768189c424a65db47058db0f7d9cf51e7d' %} +{% set i2pupdate_hash = 'b8ee5d9c88924f631ae03ffcbed4ac0b06542e51cdd144e20dbaad69a8fdcef4' %} {% set i2p_android_hash = 'b14e3cc5ea12eb2e8bccb81dd2e86eeea3baba6695eb1a9f4d9053e76aeb131d' %} {% set i2p_android_version = '0.9.22' %} From 12b9819cc5de51b1224ea9d0fa9776f967b174e1 Mon Sep 17 00:00:00 2001 From: zzz Date: Fri, 29 Jan 2016 18:46:10 +0000 Subject: [PATCH 088/114] add 25519ph --- i2p2www/pages/site/docs/spec/common-structures.html | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/i2p2www/pages/site/docs/spec/common-structures.html b/i2p2www/pages/site/docs/spec/common-structures.html index 4d6d2af9..2464ede6 100644 --- a/i2p2www/pages/site/docs/spec/common-structures.html +++ b/i2p2www/pages/site/docs/spec/common-structures.html @@ -160,6 +160,8 @@ As of release 0.9.12, other types may be supported, depending on context.

    		Offline signing, never used for Router Identities or Destinations
    EdDSA_SHA512_Ed25519320.9.15 Recent Router Identities and Destinations
    EdDSA_SHA512_Ed25519ph320.9.25Offline signing, never used for Router Identities or Destinations

    {% trans %}Notes{% endtrans %}

    @@ -211,6 +213,8 @@ As of release 0.9.12, other types may be supported, depending on context.     		Offline signing, never used for Router Identities or Destinations
    EdDSA_SHA512_Ed25519320.9.15 Recent Router Identities and Destinations
    EdDSA_SHA512_Ed25519ph320.9.25Offline signing, never used for Router Identities or Destinations

    {% trans %}Notes{% endtrans %}

    @@ -262,6 +266,8 @@ As of release 0.9.12, other types may be supported, depending on context. Offline signing, never used for Router Identities or Destinations EdDSA_SHA512_Ed25519640.9.15 Recent Router Identities and Destinations +EdDSA_SHA512_Ed25519ph640.9.25 +Offline signing, never used for Router Identities or Destinations

    {% trans %}Notes{% endtrans %}

    @@ -441,6 +447,8 @@ The defined Signing Key types are: Offline only; never used in Key Certificates for Router Identities or Destinations EdDSA_SHA512_Ed255197320.9.15 Recent Router Identities and Destinations +EdDSA_SHA512_Ed25519ph8320.9.25 +Offline only; never used in Key Certificates for Router Identities or Destinations

    @@ -485,6 +493,7 @@ Example layouts using an ElGamal Crypto Public Key and the Signing Public Key ty RSA_SHA384_30720256 RSA_SHA512_40960384 EdDSA_SHA512_Ed25519960 +EdDSA_SHA512_Ed25519ph960 From 8dfc8a143ff14ba96f144779169a5e75699a5119 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 30 Jan 2016 21:30:30 +0000 Subject: [PATCH 089/114] Add our Git mirror to the new developers page --- .../get-involved/guides/new-developers.html | 34 ++++++++++++++++--- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/i2p2www/pages/site/get-involved/guides/new-developers.html b/i2p2www/pages/site/get-involved/guides/new-developers.html index fdb8bc3b..13249293 100644 --- a/i2p2www/pages/site/get-involved/guides/new-developers.html +++ b/i2p2www/pages/site/get-involved/guides/new-developers.html @@ -3,7 +3,11 @@ {% block content_nav %}

    1. {% trans %}Basic study{% endtrans %}
      2. -
    2. {% trans %}Getting the I2P code{% endtrans %}
      3. +
    3. {% trans %}Getting the I2P code{% endtrans %} +
    4. {% trans %}Building I2P{% endtrans %}
    5. {% trans %}Development ideas{% endtrans %}
    6. {% trans %}Making the results available{% endtrans %}
      7. @@ -41,9 +45,31 @@ These will give you a good overview of how I2P is structured and what different

      {% trans %}Getting the I2P code{% endtrans %}

      {% trans -%} -For development on the i2p router or the embedded applications, -get the monotone source repository installed - short instructions: +For development on the I2P router or the embedded applications, +there are two ways to get the source code: {%- endtrans %}

      + +

      {% trans %}The easy way: Git{% endtrans %}

      +
        +
      • {% trans git_url='https://git-scm.com/' -%} +Install Git. + {%- endtrans %}
        • +
      • {% trans i2p_git='https://github.com/i2p/i2p.i2p' -%} +Get the code from the GitHub mirror: + {%- endtrans %}
        + git clone https://github.com/i2p/i2p.i2p.git +
        • +
      + +

      {% trans %}Remarks{% endtrans %}

      +

      {% trans trac='http://'+i2pconv('trac.i2p2.i2p') -%} +The Git repository is currently a read-only mirror. If you wish to use it for +development, you will need to submit patches to our issue +tracker. We can accept GitHub pull requests, but they must be processed +manually by turning them into patches anyway. +{%- endtrans %}

      + +

      {% trans %}The proper way: Monotone{% endtrans %}

      -

      {% trans %}Remarks{% endtrans %}

      +

      {% trans %}Remarks{% endtrans %}

      {% trans %} To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'. {%- endtrans %}

      From dfd098b3cd1b99c7d10ab3647319ac1a7e16db0c Mon Sep 17 00:00:00 2001 From: dev Date: Mon, 1 Feb 2016 01:07:37 +0000 Subject: [PATCH 090/114] Fleshed out the reseed text. Quickie guide from http://zzz.i2p/topics/2062 was imported. --- i2p2www/pages/site/docs/reseed.html | 210 +++++++++++++++++++++++++++- 1 file changed, 209 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/site/docs/reseed.html b/i2p2www/pages/site/docs/reseed.html index 97daa3bc..023fac4c 100644 --- a/i2p2www/pages/site/docs/reseed.html +++ b/i2p2www/pages/site/docs/reseed.html @@ -1,9 +1,12 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Reseed Services{% endtrans %}{% endblock %} {% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.23{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %} + +

      {% trans %}About Reseed hosts{% endtrans %}

      +

      {% trans -%} Reseed hosts are needed to for bootstrapping, that is providing the initial set of I2P nodes for your I2P node to talk to. Depending on the status of your node it may need to bootstrap every now and then if many of the nodes it knows of aren't contactable. {%- endtrans %}

      @@ -12,4 +15,209 @@ Reseed hosts are needed to for bootstrapping, that is providing the initial set Reseeding is done over an encrypted connection and all of the bootstrap information is signed by the reseed host you connect to, making it impossible for an unauthenticated source to provide you with false information. {%- endtrans %}

      + +

      {% trans %}How to run a Reseed host{% endtrans %}

      +Quick guide - setup a public reseed server (2016-01) + +
        +

      1. +{%-trans -%} +Fire up your favorite webserver +Connect a domain, sub-domain or (anonymous) third-level-domain +Setup a state-of-the-art TLS(SSL) certificate +Allow access only via HTTPS/TLS, no unencrypted HTTP +Allow only very good ciphers, compatible to Java 7/8/9 +Note: A non default port other than 443 can be used; TLS certificate can be self signed; configure fail2ban as bot-net protection +{%- endtrans -%} +

        2. + +

      2. +{%-trans -%} +Install git and golang-go (>=1.4.2), e.g. +{%- endtrans %} + 

        +sudo apt install git
+sudo apt install golang-go
+
        +

        3. + +

      3. +{%-trans -%} +Switch to user running i2p, fetch the i2p-tool source code, build and test it: +{%- endtrans %} + 

        +export GOPATH=$HOME/go; mkdir $GOPATH; cd $GOPATH
+go get github.com/martin61/i2p-tools
+bin/i2p-tools -h
+
        +{%-trans -%} +Note: Visit http://reseed.i2p and download a pre-build x86_64 binary, so you can skip step 2+3. +{%- endtrans -%} +

        4. + +

      4. +{%-trans -%} +Run i2p-tool locally, use your email: + 

        +GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed --signer=backup@mail.i2p --netdb=/home/i/.i2p/netDb --port=8443 --ip=127.0.0.1 --trustProxy
+
        +{%- endtrans -%} +

        5. + +

      5. +{%-trans -%} +New certificates + make a backup from the new created su3-signing key and certificate found in $GOPATH and keep it in a save password protected storage +{%- endtrans -%} +

        6. + +

      6. +{%-trans -%} +Enable autostart (+restart) for i2p-tool in your crontab: +{%- endtrans %} + 

        +@reboot   GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
+9 * * * * GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
+
        +

        7. + +

      7. +{%-trans -%} +Connect your webserver via reverse-proxy-setup to the i2p-tool, examples: +{%- endtrans %} + 

        +lighttpd configuration example:
+	server.modules += ( "mod_proxy" )
+	proxy.server = ( "i2pseeds.su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) ) )
+nginx configuration example:
+	location / {
+		proxy_pass http://127.0.0.1:8443;
+	}
+apache (sorry: untested - feedback would be appreciated)
+	ProxyRequests Off
+	
+		Order deny,allow
+		Allow from all
+	
+	ProxyPass / http://127.0.0.1:8443/
+	ProxyPassReverse / http://127.0.0.1:8443/
+
        +{%-trans -%} +Note: i2p-tool has also an build-in standalone webserver with tls support which can be used without a webserver. +{%- endtrans -%} +

        8. + +

      8. +{%-trans -%} +Final test from another computer with i2p running: +

          +
        • + place your su3-certificate (*.crt) in i2p/certificates/reseed/ +
          • +
        • + place your tls-certificate (*.crt) in i2p/certificates/ssl/ +
          • +
        • + visit with your webbrowser http://localhost:7657/configreseed +
          • +
        • + enter your new reseed-url and delete all others, hit "Save changes and reseed now" +
          • +
        • + check the i2p logs for "Reseed got 77 router infos from ... with 0 errors, Reseed complete, 77 received" +
          • +
        +{%- endtrans -%} +

        9. + +

      9. +{%-trans -%} +Go public, the following to backup@mail.i2p.de (pgp signed welcomed :-) +

          +
        • + domain/url/port +
          • +
        • + su3-signing certificate +
          • +
        • + tls certificate (if self signed) +
          • +
        +{%- endtrans -%} +

        10. + +

      10. +{%-trans -%} +public pgp key: backup@mail.i2p (0x47C68B7B): +{%- endtrans%} + 

        +-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v2
+
+mQINBFJ/XjQBEACwbcCskI/dFyYi2uqrfpckZqJ2hgoTd/peIAIz8T70CR96pWjE
+kaKRSagb1uyN97yKbDNybWzg9RqXe07AU1d98CPbWevXlfb/bZRSy0JvTJ7InucY
+AGGG0yKrY5aDb9N6OwdRawBDUw0mM6euKrHCJ2mSH3eWjN9UOgkS9JSj1sYDDPsC
+cmY2TPbWg1O8jRRqgRkSogjn9KWl5oEWqY/ABYz2P0/t7woWNs0ZpzNecUVKHCa6
+z2Wgwjj+Ooesw4DdfNDam6xGLpY/mvV/znGCnJNa1wHoQDG8+WP7+EyJ9i59WdzI
+Lh35vMLDDPnjtlO26Iq8OOrVMuZC5mJrIzD9ycPHX8t89AqELzLie3g/HlrGCCKV
+HGWJjfjglwvza5OmiletofSMFbLZY6DBxE4iNqLnozpcygezr27vJpchU1AFsZXG
+9sLQbu2YetwxAwZwiQnVey+QYNE4mb3TYj+Mq1USjT655wvYD4byARpRSHbw6flb
+eLHgO0RRN/hu0Fa700GKX8Nh2qRugQ3JaYpNkyNMHiKt75CqOSzfVv3jCaewi1dO
+ZwQHod+wRsnVfOpWMZ7LvK39LXzNyH9PX16yL6j68KueMuCtIgoq0/UJ8/0islkQ
+o7UpXn/EIhCSGNMKXgl2JVaib9i1JT+fbkik3yq3SCsNMb+p1hrvt68jQwARAQAB
+tB5iYWNrdXAgKGkycCkgPGJhY2t1cEBtYWlsLmkycD6JAjgEEwECACIFAlJ/XjQC
+GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEDiiy3nrvfHHgtEQAKmc5gzX
+mGYl9tZ8ISWPhyr8A/1hUK9Y1R/o4tQPtKYRa2b4eXyUb2zFSaXniz8LXVdielLi
+ccGinKAsHf+jJwqgh1QIQuPUrwvLud3rueHa2G6CKESDB+7n6thQYC5KAFsObHcP
+K0LDC9+Y5R5MLE47SjOnukdEqa6LWtBb9f4uQVoH4EeXkomgB0SNJORkJNuoGOlQ
+MLVTkY1EK1kECJFTbCtLL+Gri38Jfy7YaR7j4LIToNYylzNW7s7Q1l1Caq/c4Y9N
+Q3+wVrlF5zDhgR2LdEwOz5dHzG6YMxf0YNp1D6g92z2keRE+0+6EKr+hmJ30hbAh
+nB5G5/7V45ULPPdvfkE0hcahOEFhmlFUqpyTDpOZg2Vs2fhTpbsIZetyX9t75Ain
+uyGxs+NZjc/Srv2+lmBBczgMT4OYlrrskBqBCbMpSnZ0MGXf2pK+yGGofXNXDN3O
+UcfIN3AbGUrXkg4SacfPfWJdOt1hvfMEEncvamN5/YyKkcYNoku8H+HyKPh12fg3
+d+JfmskQIKqWQoZqWowAg8xQBwi1roXjz9oAvn4/8U01tjmAMtXDQVXpHCzBQDT8
+ySUOcp6DUppAt2rWnB/DAufYJ+AtR+t8O+P6fyQGIGk4CRmzTDzrztdnodGOkceG
+1GQ8JH5o/j4J6di+r/bDH/pmVqbCqIpC8L9yuQINBFJ/XjQBEADPZDezlqbPueD6
+sn7mQIKfzrsA31Go97SnZyPcHhhKEoba493+Dh975v/wCILWvdKIvmtZ5aAs3oC3
+S8N7OV5oYiY/3rEU+1NaUl7DhM0XtPTpFkpaIzgmK+fqCzcn23Hqd8affqy/2rjt
+Z1uRylCLKTMYHquLMl2+1cpcEeCVfEnZ7ExkJVIcIQ2ZU/DmyeZr2n6T9MTmvz6I
+io7OBIMoAxFvq7QC2HffhKj/yfj3kRue5Y+WRkUD2sOqv3Cd/WoYQkhttgegtmoW
+BNIQfygYGqLrXl7MGKCBoFmsSoDRK5+SejuZYE9Ndt9oKnkrkJnojy7FYArR/9x6
+y9crFXVX9urCOncbF5S9O+SHvmFP+wtOnNtzaPPVwuClgOdkLJWKsYJFgZgy9EMF
+wGL/jpV3jWTMFwyJspi0+utlGWqt6ubIA4/5/tUyO4pCYl4rgxx8nSHokt97WmF3
+CAdVpF8iDRzQxxWIHnE77pIMvymXliJv0zO9dLPzaujuGEG14ZiCrXFJNB/JY5/C
+1nS8RxDZksTBaw1VPDlR6Cwf38JqZy3dDCxkAgX2mQRAMvZ92HrI/vhZtBkwxN6I
+F6SdMjMG2ArPmRl0Efsy5Ztfs3OVX4nHq+pzGc8TOdaRbKPT3FhLAhkX8QRN7v+a
+Cvqh/HepVIQ45Kpsoadgdz8hM5ktWQARAQABiQIfBBgBAgAJBQJSf140AhsMAAoJ
+EDiiy3nrvfHHnUsP/RjhWGzv/Z6sYn0sAtn3yoJrPlwz7GcqKflrKweUE2EwCueq
+azFSu7Y+lJMOrInw1K9fELFdbrSgGQYSc8Cia42UoQeksDffUWS/nhNU3FzTeAnU
+w8BHFhVriRUHRkK6ng5H5TEiDsqbwKeqvBoBBIf4WIyhwUinvFVCBmMKt0hdCjqh
+Q70VCyCLFN4aEjd5F6CQK8Dcf7oe5n4izz7lZdV5TtWJDZliIIgV5cvYeTBTYtMF
+ZYaUpfYQoAQ/2NrQx94ScATRqIaSAsJr11kePPVt2ooMzIqKCXsOxFubvEPsoPgD
+zIoeHYFGrUNVgP1/JobpDp0qPF74GKlBU8XxB3udtBdoReMDieYCl89tEE5AAefo
+r/hvgdWIH9IBRlVPBQBIjzun9CO1dwl8gYx+zZvzpLY2gCBY6U0U7GsbDxFzjKHM
+1fgy9a8PVdAG/2RJmeU1hpGB5DlTvuPhMwqDXjRtFGcBuYUTy10SLfM6oyb6mgiO
+4ZfSSTcEtkf1SW3qGAx5tixuM5QHAi/7w4+EXd3lQCfSMwTCh6fOKI5O+GcIjR1u
+AfYhHnMBf5KOduLoVS4PMXrCX9469ZHpMf8pSNwLFMWvGGqA1ofhsr8rTU6HcgFz
+TIUlPrFCohH5RDTwemwaJHvAShs9f5wU2Jz8+Z/Jr39ALg4C/lFuOTYh9lEp
+=W/+s
+-----END PGP PUBLIC KEY BLOCK-----
+
        +

        11. +
      + +

      {% trans %}Thank you{% endtrans %}

      +

      +{%-trans -%} +If you are running a reseed server, I would like to thank you for helping to +make the I2P network stronger and more resiliant than ever. +{%- endtrans-%} +

      +

      +{%-trans -%} +Thank you. +{%- endtrans-%} +

      + {% endblock %} From 6620b4ca8ec808d9fb56fb7b3db3f36f967ae7ba Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 1 Feb 2016 13:25:31 +0000 Subject: [PATCH 091/114] fix broken business week article link --- i2p2www/pages/site/about/media.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/site/about/media.html b/i2p2www/pages/site/about/media.html index dccfda40..72682713 100644 --- a/i2p2www/pages/site/about/media.html +++ b/i2p2www/pages/site/about/media.html @@ -1,5 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Presentations on I2P') }}{% endblock %} +{% block lastupdated %}January 2016{% endblock %} {% block content %}

      {% trans papers=site_url('papers') -%} Following are links to presentations, videos, and tutorials about I2P. Links to research papers on I2P are available here. @@ -203,8 +204,9 @@ Lance James (0x90) Interviewed by El País October 31, 2002. {%- endtrans %} -

    7. {% trans link='http://www.businessweek.com/magazine/content/03_37/b3849089_mz063.htm' -%} +
    8. {% trans link='http://www.bloomberg.com/bw/stories/2003-09-14/the-underground-internet' -%} 2003 Business Week article referencing invisiblenet +September 14, 2003. {%- endtrans %}
    9. {% trans link='http://www.netzwelt.de/news/75371-i2p-das-anonyme-netz-im.html' -%} From baa9aa9e24aa0df3784d184ba46dee35d47d11e4 Mon Sep 17 00:00:00 2001 From: dev Date: Mon, 1 Feb 2016 19:03:51 +0000 Subject: [PATCH 092/114] Reworked reseed page. --- i2p2www/pages/site/docs/reseed.html | 201 ++-------------------------- 1 file changed, 12 insertions(+), 189 deletions(-) diff --git a/i2p2www/pages/site/docs/reseed.html b/i2p2www/pages/site/docs/reseed.html index 023fac4c..29471bff 100644 --- a/i2p2www/pages/site/docs/reseed.html +++ b/i2p2www/pages/site/docs/reseed.html @@ -1,5 +1,5 @@ {% extends "global/layout.html" %} -{% block title %}{% trans %}Reseed Services{% endtrans %}{% endblock %} +{% block title %}{% trans %}Reseed Hosts{% endtrans %}{% endblock %} {% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} {% block accuratefor %}0.9.24{% endblock %} {% block content %} @@ -16,196 +16,19 @@ Reseeding is done over an encrypted connection and all of the bootstrap informat {%- endtrans %}

      -

      {% trans %}How to run a Reseed host{% endtrans %}

      -Quick guide - setup a public reseed server (2016-01) - -
        -

      1. -{%-trans -%} -Fire up your favorite webserver -Connect a domain, sub-domain or (anonymous) third-level-domain -Setup a state-of-the-art TLS(SSL) certificate -Allow access only via HTTPS/TLS, no unencrypted HTTP -Allow only very good ciphers, compatible to Java 7/8/9 -Note: A non default port other than 443 can be used; TLS certificate can be self signed; configure fail2ban as bot-net protection -{%- endtrans -%} -

        2. - -

      2. -{%-trans -%} -Install git and golang-go (>=1.4.2), e.g. +

        {% trans %}Running a Reseed host{% endtrans %}

        +

        +{% trans -%} +The more reseed hosts that are run, the more resiliant the I2P network becomes, and the harder it is to prevent users of I2P from connecting to the network. {%- endtrans %} - 

        -sudo apt install git
-sudo apt install golang-go
-
        -

        3. - -

      3. -{%-trans -%} -Switch to user running i2p, fetch the i2p-tool source code, build and test it: +

        +{% trans -%} +There have also been cases where the reseed hosts we had, have been under heavy load due to botnet activities. {%- endtrans %} - 
        -export GOPATH=$HOME/go; mkdir $GOPATH; cd $GOPATH
-go get github.com/martin61/i2p-tools
-bin/i2p-tools -h
-
        -{%-trans -%} -Note: Visit http://reseed.i2p and download a pre-build x86_64 binary, so you can skip step 2+3. -{%- endtrans -%} -

        4. - -

      4. -{%-trans -%} -Run i2p-tool locally, use your email: - 

        -GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed --signer=backup@mail.i2p --netdb=/home/i/.i2p/netDb --port=8443 --ip=127.0.0.1 --trustProxy
-
        -{%- endtrans -%} -

        5. - -

      5. -{%-trans -%} -New certificates - make a backup from the new created su3-signing key and certificate found in $GOPATH and keep it in a save password protected storage -{%- endtrans -%} -

        6. - -

      6. -{%-trans -%} -Enable autostart (+restart) for i2p-tool in your crontab: -{%- endtrans %} - 

        -@reboot   GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
-9 * * * * GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
-
        -

        7. - -

      7. -{%-trans -%} -Connect your webserver via reverse-proxy-setup to the i2p-tool, examples: -{%- endtrans %} - 

        -lighttpd configuration example:
-	server.modules += ( "mod_proxy" )
-	proxy.server = ( "i2pseeds.su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) ) )
-nginx configuration example:
-	location / {
-		proxy_pass http://127.0.0.1:8443;
-	}
-apache (sorry: untested - feedback would be appreciated)
-	ProxyRequests Off
-	
-		Order deny,allow
-		Allow from all
-	
-	ProxyPass / http://127.0.0.1:8443/
-	ProxyPassReverse / http://127.0.0.1:8443/
-
        -{%-trans -%} -Note: i2p-tool has also an build-in standalone webserver with tls support which can be used without a webserver. -{%- endtrans -%} -

        8. - -

      8. -{%-trans -%} -Final test from another computer with i2p running: -

          -
        • - place your su3-certificate (*.crt) in i2p/certificates/reseed/ -
          • -
        • - place your tls-certificate (*.crt) in i2p/certificates/ssl/ -
          • -
        • - visit with your webbrowser http://localhost:7657/configreseed -
          • -
        • - enter your new reseed-url and delete all others, hit "Save changes and reseed now" -
          • -
        • - check the i2p logs for "Reseed got 77 router infos from ... with 0 errors, Reseed complete, 77 received" -
          • -
        -{%- endtrans -%} -

        9. - -

      9. -{%-trans -%} -Go public, the following to backup@mail.i2p.de (pgp signed welcomed :-) -

          -
        • - domain/url/port -
          • -
        • - su3-signing certificate -
          • -
        • - tls certificate (if self signed) -
          • -
        -{%- endtrans -%} -

        10. - -

      10. -{%-trans -%} -public pgp key: backup@mail.i2p (0x47C68B7B): -{%- endtrans%} - 

        ------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v2
-
-mQINBFJ/XjQBEACwbcCskI/dFyYi2uqrfpckZqJ2hgoTd/peIAIz8T70CR96pWjE
-kaKRSagb1uyN97yKbDNybWzg9RqXe07AU1d98CPbWevXlfb/bZRSy0JvTJ7InucY
-AGGG0yKrY5aDb9N6OwdRawBDUw0mM6euKrHCJ2mSH3eWjN9UOgkS9JSj1sYDDPsC
-cmY2TPbWg1O8jRRqgRkSogjn9KWl5oEWqY/ABYz2P0/t7woWNs0ZpzNecUVKHCa6
-z2Wgwjj+Ooesw4DdfNDam6xGLpY/mvV/znGCnJNa1wHoQDG8+WP7+EyJ9i59WdzI
-Lh35vMLDDPnjtlO26Iq8OOrVMuZC5mJrIzD9ycPHX8t89AqELzLie3g/HlrGCCKV
-HGWJjfjglwvza5OmiletofSMFbLZY6DBxE4iNqLnozpcygezr27vJpchU1AFsZXG
-9sLQbu2YetwxAwZwiQnVey+QYNE4mb3TYj+Mq1USjT655wvYD4byARpRSHbw6flb
-eLHgO0RRN/hu0Fa700GKX8Nh2qRugQ3JaYpNkyNMHiKt75CqOSzfVv3jCaewi1dO
-ZwQHod+wRsnVfOpWMZ7LvK39LXzNyH9PX16yL6j68KueMuCtIgoq0/UJ8/0islkQ
-o7UpXn/EIhCSGNMKXgl2JVaib9i1JT+fbkik3yq3SCsNMb+p1hrvt68jQwARAQAB
-tB5iYWNrdXAgKGkycCkgPGJhY2t1cEBtYWlsLmkycD6JAjgEEwECACIFAlJ/XjQC
-GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEDiiy3nrvfHHgtEQAKmc5gzX
-mGYl9tZ8ISWPhyr8A/1hUK9Y1R/o4tQPtKYRa2b4eXyUb2zFSaXniz8LXVdielLi
-ccGinKAsHf+jJwqgh1QIQuPUrwvLud3rueHa2G6CKESDB+7n6thQYC5KAFsObHcP
-K0LDC9+Y5R5MLE47SjOnukdEqa6LWtBb9f4uQVoH4EeXkomgB0SNJORkJNuoGOlQ
-MLVTkY1EK1kECJFTbCtLL+Gri38Jfy7YaR7j4LIToNYylzNW7s7Q1l1Caq/c4Y9N
-Q3+wVrlF5zDhgR2LdEwOz5dHzG6YMxf0YNp1D6g92z2keRE+0+6EKr+hmJ30hbAh
-nB5G5/7V45ULPPdvfkE0hcahOEFhmlFUqpyTDpOZg2Vs2fhTpbsIZetyX9t75Ain
-uyGxs+NZjc/Srv2+lmBBczgMT4OYlrrskBqBCbMpSnZ0MGXf2pK+yGGofXNXDN3O
-UcfIN3AbGUrXkg4SacfPfWJdOt1hvfMEEncvamN5/YyKkcYNoku8H+HyKPh12fg3
-d+JfmskQIKqWQoZqWowAg8xQBwi1roXjz9oAvn4/8U01tjmAMtXDQVXpHCzBQDT8
-ySUOcp6DUppAt2rWnB/DAufYJ+AtR+t8O+P6fyQGIGk4CRmzTDzrztdnodGOkceG
-1GQ8JH5o/j4J6di+r/bDH/pmVqbCqIpC8L9yuQINBFJ/XjQBEADPZDezlqbPueD6
-sn7mQIKfzrsA31Go97SnZyPcHhhKEoba493+Dh975v/wCILWvdKIvmtZ5aAs3oC3
-S8N7OV5oYiY/3rEU+1NaUl7DhM0XtPTpFkpaIzgmK+fqCzcn23Hqd8affqy/2rjt
-Z1uRylCLKTMYHquLMl2+1cpcEeCVfEnZ7ExkJVIcIQ2ZU/DmyeZr2n6T9MTmvz6I
-io7OBIMoAxFvq7QC2HffhKj/yfj3kRue5Y+WRkUD2sOqv3Cd/WoYQkhttgegtmoW
-BNIQfygYGqLrXl7MGKCBoFmsSoDRK5+SejuZYE9Ndt9oKnkrkJnojy7FYArR/9x6
-y9crFXVX9urCOncbF5S9O+SHvmFP+wtOnNtzaPPVwuClgOdkLJWKsYJFgZgy9EMF
-wGL/jpV3jWTMFwyJspi0+utlGWqt6ubIA4/5/tUyO4pCYl4rgxx8nSHokt97WmF3
-CAdVpF8iDRzQxxWIHnE77pIMvymXliJv0zO9dLPzaujuGEG14ZiCrXFJNB/JY5/C
-1nS8RxDZksTBaw1VPDlR6Cwf38JqZy3dDCxkAgX2mQRAMvZ92HrI/vhZtBkwxN6I
-F6SdMjMG2ArPmRl0Efsy5Ztfs3OVX4nHq+pzGc8TOdaRbKPT3FhLAhkX8QRN7v+a
-Cvqh/HepVIQ45Kpsoadgdz8hM5ktWQARAQABiQIfBBgBAgAJBQJSf140AhsMAAoJ
-EDiiy3nrvfHHnUsP/RjhWGzv/Z6sYn0sAtn3yoJrPlwz7GcqKflrKweUE2EwCueq
-azFSu7Y+lJMOrInw1K9fELFdbrSgGQYSc8Cia42UoQeksDffUWS/nhNU3FzTeAnU
-w8BHFhVriRUHRkK6ng5H5TEiDsqbwKeqvBoBBIf4WIyhwUinvFVCBmMKt0hdCjqh
-Q70VCyCLFN4aEjd5F6CQK8Dcf7oe5n4izz7lZdV5TtWJDZliIIgV5cvYeTBTYtMF
-ZYaUpfYQoAQ/2NrQx94ScATRqIaSAsJr11kePPVt2ooMzIqKCXsOxFubvEPsoPgD
-zIoeHYFGrUNVgP1/JobpDp0qPF74GKlBU8XxB3udtBdoReMDieYCl89tEE5AAefo
-r/hvgdWIH9IBRlVPBQBIjzun9CO1dwl8gYx+zZvzpLY2gCBY6U0U7GsbDxFzjKHM
-1fgy9a8PVdAG/2RJmeU1hpGB5DlTvuPhMwqDXjRtFGcBuYUTy10SLfM6oyb6mgiO
-4ZfSSTcEtkf1SW3qGAx5tixuM5QHAi/7w4+EXd3lQCfSMwTCh6fOKI5O+GcIjR1u
-AfYhHnMBf5KOduLoVS4PMXrCX9469ZHpMf8pSNwLFMWvGGqA1ofhsr8rTU6HcgFz
-TIUlPrFCohH5RDTwemwaJHvAShs9f5wU2Jz8+Z/Jr39ALg4C/lFuOTYh9lEp
-=W/+s
------END PGP PUBLIC KEY BLOCK-----
-
        -

        11. -
      +

      +

      +How to run a Reseed host +

      {% trans %}Thank you{% endtrans %}

      From 62d3681da0328d3198a289e1cea151897461f84d Mon Sep 17 00:00:00 2001 From: lazygravy Date: Tue, 2 Feb 2016 01:43:15 +0000 Subject: [PATCH 093/114] Writing improvements from comradenosebleed. --- i2p2www/blog/2016/01/23/32C3.rst | 75 +++++++++++++++++++++----------- 1 file changed, 49 insertions(+), 26 deletions(-) diff --git a/i2p2www/blog/2016/01/23/32C3.rst b/i2p2www/blog/2016/01/23/32C3.rst index 5898a257..eca5c13e 100644 --- a/i2p2www/blog/2016/01/23/32C3.rst +++ b/i2p2www/blog/2016/01/23/32C3.rst @@ -16,45 +16,66 @@ Attending: Sadie, Colin, lazygravy, zzz, hottuna, kytv, cacapo, and eche|on. {% trans -%} Start ===== -Wooo! Another successful year at CCC. -A huge shoutout to the angels and organizers at `32C3`_. -Just like previous years, we were located in Noisy Square to the right of the EFF's table. -Many were able to attend due to the generous donations. -As always, there was a lot of interest in I2P, and we were able to talk to many people who we otherwise would not have had the ability to. +The project has had another successful year at CCC. +We would like to thank the volunteers at `32C3`_ for all of their help in organizing this event and for being accommodating hosts for us. +Many I2P contributors were able to attend this year's Congress due to many of the generous donations from supporters like you to the project. +If you would like to fund I2P, please see `our donation page`_ for more information. {%- endtrans %} .. _{% trans %}`32C3`{% endtrans %}: https://events.ccc.de/congress/2015/wiki/Static:Main_Page +.. _{% trans %}`our donation page`{% endtrans %}: {{ site_url() }}get-involved/donate {% trans -%} -The Year of Usability! -====================== +Just like previous years we were located in Noisy Square, located near the EFF's table. +This proved to be an ideal spot for us as our table was almost always busy with current and new users who were interested in I2P, many of whom we wouldn't have otherwise had the ability to talk to. +{%- endtrans %} + +{# + +{% trans -%} +The Year of Usability +===================== {%- endtrans %} {% trans -%} -There was a lot of talk about the usability of the router console. -Many people noted that their best experience with I2P was through Vuze/I2PBote-Android. -Currently there are vague discussions of redoing the current router console since it is a bit abrasive for new users to understand. +A common discussion point at the table was the usability of the router console, and how it can be better improved for all I2P users, with a specific focus on new users. +Many (both developers and users) have mentioned to us that their best experience with I2P was through `Vuze`_ and the `I2PBote Android app`_. +Currently there are vague discussions of redoing the current router console since it is difficult for many users to understand. +{%- endtrans %} + +.. _{% trans %}`Vuze`{% endtrans %}: https://wiki.vuze.com/w/I2PHelper_HowTo +.. _{% trans %}`I2PBote Android app`{% endtrans %}: https://play.google.com/store/apps/details?id=i2p.bote.android + +{% trans -%} {%- endtrans %} {% trans -%} We need your feedback! Even if you don't use I2P often, we want to know what you think. -There are lots of ways to contact us, Twitter, or email. -See the `contacts page`_. +Please `get in touch with us`_ and let us know what improvements or ideas you have! {%- endtrans %} -.. _{% trans %}`contacts page`{% endtrans %}: {{ site_url() }}contact +.. _{% trans %}`get in touch with us`{% endtrans %}: {{ site_url() }}contact + +#} {% trans -%} Reseed Status ============= {%- endtrans %} +{% trans -%} Let's get more reseeds! +{%- endtrans %} + +{% trans -%} +If you don't know what a reseed server is, it is first the connection new routers use to find peers. There was a lot of discussion around the current status of the reseed network right now. As always, more reseed operators are needed! -If you don't know, a reseed server is the server new routers contact to find peers. -If you have the resources to run a reseed, (or if you're talented in Go) email backup -at- i2pmail.i2p. +If you would like to strengthen the reseed infrastructure, (or if you're talented with Go) email `backup -at- i2pmail.org`_. +{%- endtrans %} + +.. _{% trans %}`backup -at- i2pmail.org`{% endtrans %}: mailto:backup -at- i2pmail.org?subject=How%20Do%20I%20Run%20a%20Reseed%20Node? {% trans -%} Sybil Detection (beta) @@ -62,11 +83,11 @@ Sybil Detection (beta) {%- endtrans %} {% trans -%} -Due to the decentralized nature of I2P, detecting Sybil attacks is not as straight forward as on other networks (i.e. tor). -To Mitigate this, zzz has been working on a new router-based Sybil detection tool. -To be brief, the tool runs in the router, and collects information on floodfills your router is using. -Right now, the tool is mainly collecting a baseline, and does not act on any of the information it is collecting. -Expect to see a writeup on this more as 0.9.25 or 0.9.26 approaches, as it is still in active development! +Due to the decentralized nature of I2P detecting Sybil attacks is not as straight forward as on other networks (i.e. Tor). +To mitigate this zzz has been working on a new router-based Sybil detection tool. +To be brief, the tool runs in the router, and collects information on floodfills your router is currently aware of. +Currently the tool is mainly collecting a baseline and does not act on any of the information it is collecting. +Expect to see a writeup on this more as 0.9.25 or 0.9.26 approaches, as it is still in active development {%- endtrans %} {% trans -%} @@ -82,19 +103,21 @@ The meeting focused on organizationally preparing for more project management, a .. _{% trans %}`meeting`{% endtrans %}: {{ site_url() }}meetings/241 {% trans -%} -We discussed how much of the awesome work done on I2P is lost in the commits. -Meaning that to non-developers, there is nothing to see. -To remedy this lazygravy plans on preparing a series of technical posts explaining some technical topics in I2P. -For example, but not limited to, encrypted lease sets, why different tunnel types are needed, some observations seen in [i2spy](GITHUB LINK). +We discussed how much of the work done on I2P is lost in the commits and there is not much to see for our users. +To remedy this lazygravy plans on preparing a series of posts explaining some technical topics in I2P. +The initial ideas that we discussed writing posts on are what encrypted lease sets are, why different tunnel types are needed, and some observations seen in `I2Spy`_. +But these are just the start and we would like to hear feedback on topics we should write about! {%- endtrans %} +.. _{% trans %}`i2spy`{% endtrans %}: https://github.com/chris-barry/i2spy + {% trans -%} Meeting (Future) ================ {%- endtrans %} {% trans -%} -There will be a `another meeting`_ on 2 Feburary 2016 to discuss... +There will be a `another meeting`_ on 2 Feburary 2016 to discuss: {%- endtrans %} - {% trans -%}Review of assigned tasks from 30 December meeting{% endtrans %} @@ -102,5 +125,5 @@ There will be a `another meeting`_ on 2 Feburary 2016 to discuss... - {% trans -%}GMP 6 readiness{% endtrans %} - {% trans -%}A proposal for a code of conduct{% endtrans %} -.. _{% trans %}`another meeting`{% endtrans %}: http://zzz.i2p/topics/2014-meeting-tues-feb-2-8-pm-utc +.. _{% trans %}`another meeting`{% endtrans %}: http://{{ i2pconv('zzz.i2p') }}/topics/2014-meeting-tues-feb-2-8-pm-utc From b925f8cc1e5c26c266579aca1776a0dedeeb55b5 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 2 Feb 2016 13:30:33 +0000 Subject: [PATCH 094/114] Reseed: Add new go quick start guide from backup Move PHP docs to the bottom, mark not recommended Spelling fixes in overview --- i2p2www/pages/site/docs/reseed.html | 8 +- .../site/get-involved/guides/reseed.html | 1513 +++++++++-------- 2 files changed, 806 insertions(+), 715 deletions(-) diff --git a/i2p2www/pages/site/docs/reseed.html b/i2p2www/pages/site/docs/reseed.html index 29471bff..1582892a 100644 --- a/i2p2www/pages/site/docs/reseed.html +++ b/i2p2www/pages/site/docs/reseed.html @@ -8,7 +8,7 @@

      {% trans %}About Reseed hosts{% endtrans %}

      {% trans -%} -Reseed hosts are needed to for bootstrapping, that is providing the initial set of I2P nodes for your I2P node to talk to. Depending on the status of your node it may need to bootstrap every now and then if many of the nodes it knows of aren't contactable. +Reseed hosts are needed to for bootstrapping, that is, providing the initial set of I2P nodes for your I2P node to talk to. Depending on the status of your node it may need to bootstrap every now and then if many of the nodes it knows of aren't contactable. {%- endtrans %}

      {% trans -%} @@ -19,7 +19,7 @@ Reseeding is done over an encrypted connection and all of the bootstrap informat

      {% trans %}Running a Reseed host{% endtrans %}

      {% trans -%} -The more reseed hosts that are run, the more resiliant the I2P network becomes, and the harder it is to prevent users of I2P from connecting to the network. +The more reseed hosts that are run, the more resilient the I2P network becomes, and the harder it is to prevent users of I2P from connecting to the network. {%- endtrans %}

      {% trans -%} @@ -33,8 +33,8 @@ There have also been cases where the reseed hosts we had, have been under heavy

      {% trans %}Thank you{% endtrans %}

      {%-trans -%} -If you are running a reseed server, I would like to thank you for helping to -make the I2P network stronger and more resiliant than ever. +If you are running a reseed server, We would like to thank you for helping to +make the I2P network stronger and more resilient than ever. {%- endtrans-%}

      diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index d838ffe9..ebe9951a 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -99,58 +99,6 @@ Thank you!

      {% trans %}Detailed Instructions{% endtrans %}

      -

      Revision History

      -
      -
-2015-10-08 backup
-* self-signed ssl-certificate with EC signature + key
-* updated start-script for matts solution - "seedserver"
-* ==> howto_public_reseed_server_v7.txt
-
-2015-05-09 backup
- * new chapter: reverse-proxy setup (idea by kytv and review from matt)
- * ==> howto_public_reseed_server_v6.txt
-
-2015-03-23 backup (with much help from matt)
- * Script - su3.php - added support for running INSIDE i2p-net (DESTB32)
- * Script - su3.php - added proper html header for downloading in any browser
- * Script - cronjob_i2p.sh - minor code cleanups
- * Script - cronjob_i2p.sh - added FINAL CHECK number su3-files
- * new chapter: Optional - setup a manual reseed method, secured by captcha
- * new chapter: matt's go solution - Overview
- * new chapter: matt's go solution - Building from source
- * new chapter: matt's go solution - Run the reseed server
- * new chapter: matt's go solution - Draft for startup script
- * new chapter: matt's go solution - Convert existing Java keystore to crt- and pem-file
- * ==> howto_public_reseed_server_v5.txt
-
-2015-01-22 backup	
- * Script - cronjob_i2p.sh - minor code cleanups with shell script validator/parser
- * Script - su3.php - minor code cleanup (404 redirect), thanks to "drgr33n"
- * we want only HTTPS accessible reseed server
- * Testings - added some wget options for the ssl-certificate, thanks to "drgr33n"
- * ==> howto_public_reseed_server_v4.txt
-
-2014-12-26 backup
- * Script - cronjob_i2p.sh - config variable "target" without ending "/"
- * meeh completely removed in contacts
- * new chapter: reseed server domain/url/port exchange
- * chapter "requirements" expanded - traffic volume, attacks, web server-port!=443
- * chapter "Create self-signed ssl-certificate" - use rsa, not ecdsa
- * ==> howto_public_reseed_server_v3.txt
-
-2014-12-13 backup
- * new chapter: Create self-signed ssl-certificate
- * new chapter: Seamless ssl-cert exchange
- * meeh's solution removed
- * cronjob_i2p.sh: example target path changed to "/var/www/su3/" for clarification
- * ==> howto_public_reseed_server_v2.txt
-
-2014-10-17 backup
- * initial release v1
-
-
      -

      How-to Public reseed servers - su3

      @@ -165,8 +113,34 @@ Thank you!

      Table of contents

        -
      1. Intro +
      2. Introduction
      3. Requirements +
      4. Go solution - Quick Guide +
          +
        1. Start web server +
        2. Install git and golang +
        3. Build and test +
        4. Run reseed +
        5. Backup certificates and keys +
        6. Enable autostart +
        7. Connect web server to reseed +
        8. Test from another computer +
        9. Send us your certificates +
        + + +
      5. Go solution -Detailed Guide +
          +
        1. Go solution - Building from source +
        2. Go solution - Run the reseed server +
        3. Go solution - Draft for startup script +
        4. Go solution - reverse-proxy setup +
        5. Go solution - Convert existing Java keystore to crt- and pem-file +
        + + +
      6. PHP solution - Not recommended +
        1. Short overview
        2. su3-file guidelines for reseeding
        3. How to prepare your key pair for su3-files @@ -183,17 +157,12 @@ Thank you!
        4. Script - cronjob_i2p.sh
        5. Script - su3.php
        6. Optional - setup a manual reseed method -
        7. matt's go solution - Overview -
        8. matt's go solution - Building from source -
        9. matt's go solution - Run the reseed server -
        10. matt's go solution - Draft for startup script -
        11. matt's go solution - reverse-proxy setup -
        12. matt's go solution - Convert existing Java keystore to crt- and pem-file +
      -

      1. Intro

      +

      1. Introduction

      Public reseed servers are necessary to bootstrap into the I2P net. New installed I2P routers needs one-time about one hundred RouterInfo's (RI) as jump start. @@ -219,7 +188,7 @@ one su3-file within 24h for one client IP.

      -

      2. Requirements

      +

      2. Requirements

      Requirements for running a public reseed server: @@ -240,686 +209,126 @@ This How-to is tested with Ubuntu/Debian The web server has to be public reachable from all over the world, an eepsite inside I2P can be setup in addition. Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server. The web server doesn't need to listen at default SSL/TSL port 443 - any other port can be used for obfuscation. +

      +

      3. Go solution - Quick Guide

      - -

      3. Short overview

      - -
        -
      • permanent: run your I2P router -
      • once: generate a private and public key pair for signing the reseed files -
      • once: setup the PHP script on the web server -
      • once: setup a rewrite rule at web server (*.su3 --> su3.php) -
      • regularly: run the Unix shell script to generate up-to-date su3-files -
      • regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web server -
      - - - -

      4. su3-file guidelines for reseeding

      - +

      1. Fire up your favorite webserver

      +
      1. + connect a domain, sub-domain or (anonymous) third-level-domain +
      2. + setup a state-of-the-art TLS(SSL) certificate +
      3. + allow access only via HTTPS/TLS, no unencrypted HTTP +
      4. + allow only very good ciphers, compatible to Java 7/8/9 +

      -(From zzz.i2p) -

        -
      • The su3-file must be named "i2pseeds.su3" -
      • The file must be in the same directory as the routerinfos on the web server -
      • Router will first try to fetch (index url)/i2pseeds.su3; - if that fails it will fetch (index url) and then fetch the individual RI files, old-style -
      • Once a reseed from a host succeeds, it won't try any other URLs from that host - (either http or https, ignoring ports... ports are now implemented) -
      • RI files in the zip file (in the su3-file) must be at the "top level", - i.e. no directories in the zip file -
      • su3 content type must be RESEED (-c 3 or -c RESEED) -
      • su3 signature type should be RSA 4096 (-t 6 or -t RSA_SHA512_4096). - If you're very low on CPU power you could use a shorter key, but you only need to do the signing process once a day or so. - Any sig type will work, but RSA 4096 is the best in this case. -
      • Of course we must have your su3 signing public key checked in - under the same name as you are using in the signing process, - e.g. for you@mail.i2p the file name must be you_at_mail.i2p.crt, in the certificates/reseed/ directory -
      +Note: A non default port other than 443 can be used; TLS certificate can be self signed; configure fail2ban as bot-net protection +

      - -

      5. How to prepare your key pair for su3-files

      - -

      -( from zzz.i2p) -

        -
      • Details are posted here from zzz: zzz.i2p -
      • Who? All owner of a public reseed server. -
      • Why? su3 reseed files will be signed with your private key. -
      • This ensures a secure bootstrap for I2P routers. -
      • Corresponding public keys will be included in I2P router package. -
      - -

      -Example to create your key pair: +

      2. Install git and golang-go (1.4.2 or higher)

      -	su - i2puser
-	I2P=/home/i2puser/i2p
-	cd $I2P
-	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File keygen -t RSA_SHA512_4096 backup_at_mail.i2p.crt keystore.ks backup@mail.i2p
-
      -

      -Short usage help: -

      -	SU3File keygen [-t type|code] publicKeyFile keystore.ks you@mail.i2p
-
      -

      -Get more help: -

      -	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File
-
      -

      -Provide a strong password for your private key. -In this example two new files will be created in the working folder: -

        -
      • backup_at_mail.i2p.crt will contain the public key -
      • keystore.ks is the Java keystore file and contains your private key -
      -

      -Backup and store public key, private key and your password! -Remember also the used key size/type when not using default RSA_SHA512_4096. -Send the public .crt key file to us, to include it into i2p/certificates/reseed/ -If you have mtn privs, you may check the (you)_at_mail.i2p.crt file directly into installer/resources/certificates/reseed . -The file name must be (email address used for signing).crt, with "@" replaced with "_at_". -There is no requirement that it be xxx@mail.i2p, any email is fine, or for that matter any identifier. - - - - -

      6. su3 server-side implementation

      - -

      -(from zzz.i2p) -This describes a mechanism for creating and distributing the RI in new su3 format. -It's independent from legacy way of doing (fetching dat-files) and can be used in parallel. -This idea doesn't need mysql, only some Unix shell tools and a simple web server with PHP works fine. - -

      -A requesting client gets ~75 RI packed into one zip, signed and converted to a su3-file. -Don't provide unlimited RI to one clients. -But don't try to keep track of million client IP's in a database, e.g think of ipv6. -Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo. -n is the unlimited IPv4+IPv6 address space, and m are e.g. 100 pre-calculated su3-files. -A client with one IP gets always the same su3-file, until the su3-file is updated or the client has a new IP. -A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in I2P net grow. - -

      -Once or twice a week (or daily): pre-calculate ~100 new su3-files, each includes ~75 RI. -The RI are fetched from a well running I2P router's netdb directory. -Transfer the pre-calculate su3-files to your web server, e.g. by sftp or copy them locally to /var/www/su3/. -In the web server a PHP script will match one client IP to one of the 100 su3-files by hash+modulo. -This has the advantage to split su3-generation and publishing in web server . - -

      -Requirements for su3-file generation: -

        -
      • 24/7 running i2p-router with up to date netdb -
      • ziptool, e.g. "zip" (Debian/Ubuntu: sudo apt-get install zip) -
      • Unix shell: find, awk, cat, ... -
      • your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password -
      -Requirements for web server : -
        -
      • PHP5 -
      • rewrite rule (*.su3 --> PHP) -
      - -The following solution for a public reseed server consists of three parts: -
        -
      • Unix shell script for cronjob -
      • PHP script -
      • url rewrite rule -
      -They are described on the following chapters in more detail. - - - - -

      7. Unix shell script for cronjob

      - -

      -This script pre-calculates n su3-files. -Requirements: Unix shell, Java, I2P, zip-tool, your private reseed signing key -Main Steps: -

      -# CONFIG
-# CHECK REQUIREMENT
-# CREATE index files from netdB: use only 66% and max. 10h old
-# CREATE zip files
-# CREATE su3 files
-# FINALIZE
-
      -

      -Please check and edit #CONFIG sections, please review code before use. -The resulting su3-files are placed in the "target" folder which can be changed in config section with "target". -Configure file permissions and file owner e.g. 'www-data' - see deactivated example lines. -The cronjob script runs ca. 10 seconds for generating 100 pre-calculated su3 files on a modern cpu. -The number of dat-files per su3 package is random. If you configure 75, it results in ca. 50...100 dat-files per su3-file. -The number of generated su3-files is random too, it depends on your netdb size and adapts automatically: -

        -
      • 1000 netdb entries: used for publishing: ~666, results in ~66 su3-files, each with ~75 dat-files -
      • 3000 netdb entries: used for publishing: ~1999, results in ~199 su3-files, each with ~75 dat-files -
      -

      -Only 66% of all RI from your netdb are used, netdb may be not older than 10h. -It is possible to separate cronjob script from PHP script: -Run the cronjob script on your I2P machine and then transfer the final su3-files via (s)ftp/ssh -to your web server from time to time. su3 file-size in this setup is between 50 and 100 KB per file. - - - - -

      8. Setup cronjob

      - -

      -Please add a cronjob, e.g. to run it every few days. -Add the shell script in crontab, e.g.: -

      -	crontab -e
-	23 59 * * * /usr/local/bin/cronjob_i2p.sh
-
      -

      -The hard limit for the su3-file age is 30 days. -Recommendation is to update the su3-files once every 1..10 days. - - - - -

      9. PHP script for web server

      - -

      -The su3.php script maps always one client IP to one pre-calculated su3-file. -Requirements: a web server with PHP5 -Main Steps: -

      -# CONFIG
-# HEALTH CHECK
-# COUNT su3 files
-# MAPPING Client IP to one SU3
-# PROVIDE SU3
-
      -

      -Please check and edit #CONFIG sections, please review code before use. - -

      -The date() function in the salt ensures a rotate once a day, even if su3-files are not updated daily. -To avoid scraping from attackers with big IPv4 subnet resources -(or even IPv6) some lower bytes of the client IP address are discarded: -

        -
      • IPv4: 4 byte --> 1 lowest byte -
      • IPv6: 16 bytes --> 8 lowest bytes -
      -Clients in the same "subnet" gets the same su3-file - -

      -A clients gets only different su3-file package in following circumstances: -

        -
      • when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address) -
      • at 00:00 every date (date function in PHP) -
      • when the Unix cronjob updates the su3 files -
      - - - - - -

      10. url rewrite rule for web server

      - -

      -It is mandatory that clients does not have direct access to the su3-files at the web server. -Please activate a rewrite rule for su3-files in your web server pointing to the su3.php file: -

      -	*.su3 --> su3.php?file=$1
+	sudo apt install git
+	sudo apt install golang-go
      + +

      3. Switch to user running i2p, fetch the i2p-tool source code, build and test it

      -Apache in ".htaccess": +Note: Visit http://reseed.i2p and download a pre-build x86_64 binary, so you can skip step 2+3. +

      -	Options +FollowSymlinks
-	RewriteEngine On
-	RewriteRule ^(.*\.su3)$ /su3.php?file=$1 [L]
+	export GOPATH=$HOME/go; mkdir $GOPATH; cd $GOPATH
+	go get github.com/martin61/i2p-tools
+	bin/i2p-tools -h
      -

      -lighttpd in "/etc/lighttpd/lighttpd.conf": + +

      4. Run i2p-tools locally

      -	server.modules += ( "mod_rewrite" )
-	url.rewrite-once = ( "^(.*\.su3)$" => "/su3.php?file=$1" )
+	GOPATH=$HOME/go;
+        cd $GOPATH;
+        bin/i2p-tools reseed --signer=yourname@mail.i2p --netdb=/home/i/.i2p/netDb --port=8443 --ip=127.0.0.1 --trustProxy
      + +

      5. Back up new certificates

      -We want only HTTPS accessible reseed server. -Sorted by best solution: -

        -
      • please deactivate plain HTTP, or -
      • use a redirect rule in your web server, or -
      • implement the redirect to HTTPS in the PHP code -
      + Make a backup from the new created su3-signing key and certificate found in $GOPATH and keep it in a save password protected storage +

      - -

      11. Create self-signed ssl-certificate

      - -

      -How-to generate a new self-signed ssl-certificate for HTTPS/TLS with openssl. -Example command line in Debian/Ubuntu for your.server.com: - +

      6. enable autostart (+restart) for i2p-tools in your crontab

      -$ openssl req -x509 -nodes -days 1500 -newkey rsa:4096 -sha256 -keyout your.server.com.pem -out your.server.com.pem
-...
-Country Name (2 letter code) [AU]:UK
-State or Province Name (full name) [Some-State]:your.server.com
-Locality Name (eg, city) []:your.server.com
-Organization Name (eg, company) [Internet Widgits Pty Ltd]:your.server.com
-Organizational Unit Name (eg, section) []:your.server.com
-Common Name (e.g. server FQDN or YOUR name) []:your.server.com
-Email Address []:your.server.com
+	@reboot   GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
+	9 * * * * GOPATH=$HOME/go; cd $GOPATH; bin/i2p-tools reseed ... >/dev/null 2>&1
      +

      7. connect your webserver via reverse-proxy-setup to the i2p-tool, examples

      -The result is stored in "your.server.com.pem" file - -

      -Remarks: -

        -
      • Please fill out all fields, don't use blanks -
      • rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu -
      • use rsa, not ecdsa (ecdsa will break currently RetHat users) -
      • Optional: -Instead of RSA key and signature use a EC 384 key and signature, example: -
         
-f=your.server.com
-openssl ecparam -name secp384r1 -genkey -out $f.key
-openssl req -new -x509 -key $f.key -out ${f}.crt -days 2000 -sha512
-cat $f.key $f.crt > $f.pem
-
        -This results in a EC 384 bit key with SHA512withECDSA signature. -
      • days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years)) -
      • sha256 - important, without this option openssl currently uses weak sha1 by default -
      • Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup. -
      - -

      -Next step: -

        -Open the created pem-file with a simple text editor. -You see the section with the private key and the section with the public key. -Copy the public section (starting with -----BEGIN CERTIFICATE-----) to another new file -and save the new file as your.server.com.crt file -
      - -

      -Send this to us - the .crt file with the public key section will we included in every I2P router. -The .pem file with your private key is only for you and your web server. - - - - -

      12. Seamless ssl-certificate exchange

      - -

      -The update/exchange of an already existing self-signed certificates has to be correct timed -on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange -will not be seamless possible and will have very bad impact on many clients: reseed won't work for them. - -

      -To avoid this issue and make the exchange as smooth as possible follow these simple steps: - -

        -
      1. generate a new ssl-certificate NOW, but do NOT implement it on server -
      2. send the new ssl-certificate to us to perform a roll-out towards clients NOW -
      3. WAIT some month, e.g. 3-4 i2p-releases -
      4. new ssl-certificate is now hopefully present on many clients (in parallel to the current/old one) -
      5. THEN exchange the ssl-certificate on server -
      - -

      -This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g. -server.com.crt and server.com2.crt - - - - -

      13. reseed server domain/url/port exchange

      - - -

      -You are already operating a reseed server but want to change your domain/url/port? -To make the exchange as smooth as possible for many clients please follow these steps if possible: - -

        -
      1. Setup an additional reseed instance at the new domain/url/port -
      2. we include the new url into I2P source NOW and delete the old url NOW -
      3. both of your reseed instances have to run some time in parallel -
      4. WAIT some month, e.g. 3-4 i2p-releases -
      5. new url is now hopefully present on many clients -
      6. THEN shutdown the old reseed instance -
      - - - -

      14. Tests

      - -

      -Some simple pre-test: test the website and fetch + lighttpd configuration example: +

      -	wget --user-agent="Wget/1.11.4" -O /tmp/test.su3 --no-check-certificate https://your-server.com:PORT/i2pseeds.su3
+		server.modules += ( "mod_proxy" )
+		proxy.server = ( "i2pseeds.su3" => ( ( "host" => "127.0.0.1", "port" => 8443 ) ) )
      -Replace "PORT" with default 443 or your chosen server setting. -Inspect the fetched file.: -Some simple pre-test: test the website and fetch +

      + nginx configuration example: +

      -	zipinfo -z /tmp/test.su3
-
      - -

      -Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt" -which contains the path to your local public ssl-certificate to check also your ssl-certificate chain. - -

      -Everything ok: -

        -
      • ssl-certificate chain valid? -
      • The su3-files can be downloaded? -
      • contains > 50 dat-files? -
      • and is always the same for one client-IP? -
      • other client-IP's gets another file? -
      • Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ? -
      - -

      -Do a real reseed test on *another* I2P router machine: -

        -
      • include manually new ssl-certificate into i2p installation: ~/i2p/certificates/ssl/ -
      • include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/ -
      • http://localhost:7657/configreseed --> remove all reseed hosts -
      • add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3" -
      • Save and Shutdown router. -
      • clear netdb: empty folder ./i2p/netDb. -
      • Restart I2P and watch the I2P router log: -
        -2014/10/13 23:01:02 | Reseed start
-2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
-2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
-2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
-2014/10/13 23:01:06 | Reseed complete, xx received
-
        -
      - - - - -

      15. Contact reseed maintainer

      - -

      -Contact us per email backup@mail.i2p (fallback is killyourtv@mail.i2p or the reseed section at zzz's forum) -Provide us details about the new -

        -
      • reseed website url, -
      • public part of ssl-certificate -
      • public su3-key -
      • your contact email -
      -

      -Feel free to contact backup@mail.i2p in case of questions or problems or post your question at zzz's forum in the reseed section. - - - - -

      16. Script - cronjob_i2p.sh

      -
      -###############################################################################
-#!/bin/sh
-version="v5"
-
-
-# CONFIG
-I2P="${HOME}/i2p"			# i2p installation directory
-source="${HOME}/.i2p/netDb"		# valid netdb
-target="${HOME}/i2pseeds.su3"		# location for the final su3-files
-
-key_keystore="${I2P}/keystore.ks"	# your private su3 reseed key
-key_password="secret"			# your password for private key of keystore.ks
-key_email=yourmail@mail.i2p		# your email id for reseeding
-key_type=RSA_SHA512_4096		# your key size/type for reseeding (DO NOT EDIT, unless you know why)
-
-tool_zip="/usr/bin/zip"			# install a "zip" tool: sudo apt-get install zip
-tool_i2p="$I2P/lib/i2p.jar"		# should be already there
-
-
-# CONFIG (DO NOT EDIT)
-ri_seed=75				# average number ri per su3-file (DO NOT EDIT)
-stamp=$(date +%s)			# unique id (DO NOT EDIT)
-target_tmp="/tmp/i2pseeds.${stamp}.tmp"	# temp folder with unique id (DO NOT EDIT)
-
-
-# CLEAN /tmp/i2pseeds.*
-find /tmp -type d -iname 'i2pseeds.*.tmp' -exec rm -rf {} \;
-mkdir --parents "${target_tmp}"
-
-
-# CHECK REQUIREMENT
-[ ! -d "${I2P}" ]          && echo "ERROR1: path not found: ${I2P}"          && exit 1
-[ ! -d "${source}" ]       && echo "ERROR2: path not found: ${source}"       && exit 1
-[ ! -d "${target_tmp}" ]   && echo "ERROR3: path not found: ${target_tmp}"   && exit 1
-[ ! -x "${tool_zip}" ]     && echo "ERROR4: command not found: ${tool_zip}"  && exit 1
-[ ! -f "${tool_i2p}" ]     && echo "ERROR5: file not found: ${tool_i2p}"     && exit 1
-[ ! -f "${key_keystore}" ] && echo "ERROR6: file not found: ${key_keystore}" && exit 1
-
-
-# CREATE index-files from netdB: use only 66% and max. 10h old
-find "${source}" -type f -mmin -600 -name 'routerInfo-*.dat' | awk -v ri_seed="${ri_seed}" -v target_tmp="${target_tmp}" '
-	BEGIN { ri_all=0; }
-	{	data[ri_all++]=$0; }
-	END {	srand();
-		ri_use=ri_all*0.6666;
-		ri_su3=int(ri_use/10);
-		stepy=ri_use/ri_all;
-		stepx=ri_seed/ri_use;
-		for (y=0;y<ri_all; y++) if (rand()<=stepy) {
-			for (x=0; x<ri_su3; x++) if (rand()<=stepx) {
-				file=target_tmp"/"x".index";
-				print data[y] >> file
-			}
+		location / {
+			proxy_pass http://127.0.0.1:8443;
 		}
-	}'
-
-
-# CREATE zip-files from index-files
-find "${target_tmp}" -type f -name '*.index' | sort | while read i; do
-	"${tool_zip}" --update --quiet --junk-paths "${target_tmp}/$(basename "$i" .index)" -@ < "$i"
-done
-
-
-# CREATE su3-files from zip-files
-echo "${key_password}" | java -cp "${tool_i2p}" net.i2p.crypto.SU3File bulksign -c RESEED -t "${key_type}" "${target_tmp}" "${key_keystore}" "${stamp}" "${key_email}"
-
-
-# REMOVE index-files and zip-files
-find "${target_tmp}" -type f -name '*.index' -exec rm -f "{}" \;
-find "${target_tmp}" -type f -name '*.zip'   -exec rm -f "{}" \;
-
-
-# FINAL CHECK number su3-files
-c_su3=$(find "${target_tmp}" -type f -mmin -600 -name '*.su3' | wc -l)
-[ "${c_su3}" -lt 25 ] && echo "ERROR7: less than 25 su3 files found: ${c_su3}" && rm -Rf "${target_tmp}" && exit 1
-echo "Created: $target_tmp ${c_su3} x${ri_seed}"
-
-
-# MOVE su3-files to target
-chmod 755 "${target_tmp}" -R
-rm -fr "${target}.old"
-mv -f  "${target}"     "${target}.old"
-mv -f  "${target_tmp}" "${target}"
-rm -fr "${target_tmp}"
-
-
-# EXIT
-echo      "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
-logger -t "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
-exit 0
-###############################################################################
      - - - -

      17. Script - su3.php

      +

      + apache (sorry: untested - feedback would be appreciated) +

      -###############################################################################
-<?php
-$version="v5";
-
-
-# CONFIG
-$path_su3="/home/i2p/i2pseeds.su3";		# path to pre-calculated su3 files
-$salt="change_to_something";			# change salt to something random
-$salt=$salt . date("Y-m-d");			# date() ensures a rotate once a day, even if su3 are not updated daily (DO NOT EDIT)
-$file_su3  = "i2pseeds.su3";			# static (DO NOT EDIT)
-$user_agent= "Wget/1.11.4";			# static (DO NOT EDIT)
-
-
-# INSIDE i2p-net ? If yes: convert DESTB32 into pseudo IPv6 as valid REMOTE_ADDR
-if (	$_SERVER["REMOTE_ADDR"]=="127.0.0.1"
-	&& isset($_SERVER["HTTP_X_I2P_DESTB32"])
-  ) {	$_SERVER["REMOTE_ADDR"]=inet_ntop(substr(md5($_SERVER["HTTP_X_I2P_DESTB32"]),0,16)); }
-
-
-# HEALTH CHECK 1
-if (	!isset($_SERVER['HTTP_USER_AGENT'])
-	|| !isset($_SERVER['REMOTE_ADDR'])
-	|| !isset($_GET['file'])
-    ) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
-
-
-# COUNT su3 files
-$count_su3 = count(glob($path_su3."/*.su3"));
-
-
-# HEALTH CHECK 2
-if (	empty($_SERVER['HTTP_USER_AGENT'])
-	|| empty($_SERVER['REMOTE_ADDR'])
-	|| empty($_GET['file'])
-	|| (strcmp(basename($_GET['file']), $file_su3) != 0)
-	|| (strcmp($_SERVER['HTTP_USER_AGENT'], $user_agent) != 0)
-	|| !filter_var($_SERVER['REMOTE_ADDR'], FILTER_VALIDATE_IP)
-	|| $count_su3<1
-    ) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
-
-
-# MAPPING Client IP to one su3-file
-$remote_id = inet_pton($_SERVER['REMOTE_ADDR']);
-$shrink=3; if (strlen($remote_id)>8) { $shrink=8; };
-$remote_id = abs(crc32(md5(substr($remote_id,0,$shrink).$salt))) % $count_su3;
-$file_id = $path_su3."/".$remote_id.".su3";
-
-
-# HEALTH CHECK 3
-if (!file_exists($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
-
-
-# PROVIDE su3-file
-header('Content-Description: File Transfer');
-header("Content-Type: application/zip");
-header('Content-Transfer-Encoding: binary');
-header('Content-Length: '.filesize($file_id));
-header('Content-Disposition: attachment; filename='.$file_su3);
-ob_clean(); flush();
-if (!readfile($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
-exit;
-?>
-###############################################################################
+		ProxyRequests Off
+		<Proxy *>
+			Order deny,allow
+			Allow from all
+		</Proxy>
+		ProxyPass / http://127.0.0.1:8443/
+		ProxyPassReverse / http://127.0.0.1:8443/
      - - - -

      18. Optional - setup a manual reseed method

      -For some users the automated reseeding may not work. -This is an alternate way for users to get a valid reseed file with a normal web-browser, -e.g. from another machine or maybe a friend. It is secured by a captcha to prevent abuse. +Note: i2p-tool has also an build-in standalone webserver with tls support which can be used without a webserver. +

      -

      -With this optional code users can visit https://your.reseedserver.com/reseed.php -with any web-browser to download a su3-file after they solved the captcha. -

      -Since 0.9.18-9 I2P has support to use reseed files from other sources: -http://localhost:7657/configreseed +

      8. Final test from another computer with i2p running

      +
      1. + place your su3-certificate (*.crt) in i2p/certificates/reseed/ +
      2. + place your tls-certificate (*.crt) in i2p/certificates/ssl/ +
      3. + visit with your webbrowser http://localhost:7657/configreseed +
      4. + enter your new reseed-url and delete all others, hit "Save changes and reseed now" +
      5. + check the i2p logs for "Reseed got 77 router infos from ... with 0 errors, Reseed complete, 77 received" +
      -

      -Visit https://geti2p.net/en/faq#manual_reseed to read how it works for users and see some example url's. -[NOT DONE YET: read here: zzz.i2p -or test here anonymously: reseed.i2p] -

      -The changes for an exiting reseed server with the previous setup are simple: -

        -
      • use the latest su3.php from above (minimal version 5, only minor changes, no change of logic). -
      • add the new reseed.php to your /var/www folder, next to to su3.php -
      • install php5-gd (restart of PHP processes may be necessary) -
      • get Securimage php-code from https://www.phpcaptcha.org/ -
      - -

      -Quote from https://www.phpcaptcha.org (2015-03): -"Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect -forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots. -It can run on most any web server as long as you have PHP installed, and GD support within PHP. -Securimage does everything from generating the CAPTCHA images to validating the typed code." - -

      -Short overview about installing Securimage: -

        -
      1. download at https://www.phpcaptcha.org/download/ -
      2. extract to /var/www/securimage -
      3. download and extract the "Test Script" (securimage_test.php) from the same url -
      4. test your server and visit https://.../securimage_test.php with your browser -
      -

      -The "Test Script" verifies your ability to run and display the captcha code, and can be deleted after the test. - -

      -The reseed.php contains only the captcha generation and verification of the users input. It is based on the -Quickstart Guide from Securimage. When the user solved the captcha, reseed.php sets two http variables and -then includes the external su3.php to start the su3-file download. - -

      -The name "reseed.php" is not fixed, you can name it unremarkable/unobtrusive as you like, -enter.php start.php go.php... -but you have to stick with it, when it is published :-) - -

      -reseed.php: -

      -################################################################################################
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><body>
-<?php
-session_start();
-include_once $_SERVER['DOCUMENT_ROOT'] . '/securimage/securimage.php';
-$securimage = new Securimage();
-
-if (!isset($_POST['captcha_code']) || $securimage->check($_POST['captcha_code']) == false) {?>
-	<form method="post" action="<?php echo(basename($_SERVER['PHP_SELF'])); ?>">
-	<img id="captcha" src="/securimage/securimage_show.php" alt="CAPTCHA Image" />
-	<p>Enter Code: <input type="text" name="captcha_code" size="10" maxlength="6" />
-	<input type="submit" value="Check Code" />
-	</form>
-<?php } else {
-	$_SERVER['HTTP_USER_AGENT']="Wget/1.11.4";
-	$_GET['file']="i2pseeds.su3";
-	include_once $_SERVER['DOCUMENT_ROOT'] . "/su3.php";
-} ?>
-</body></html>
-################################################################################################
-
      +

      9. Send us your information

      +
      1. + domain/url/port +
      2. + su3-signing certificate +
      3. + tls certificate (if self signed) +
      -

      19. matt's go solution - Overview

      + +

      4. Go solution - Detailed Instructions

      + +

      1. Go solution - Overview

      The previous steps for reseeding involves many steps, scripts and programs. @@ -954,13 +363,13 @@ In this case you can setup a cronjob to transfer the netDB from the I2P machine

      Matt's go solution can be used in parallel next to an already running http-server. For this leave the http-server running at normal port 80 and 443, -and configure matt's go solution too use another port, e.g. port 8443. +and configure Go solution too use another port, e.g. port 8443.

      More: at github, README.md, https://github.com/MDrollette/i2p-tools -

      20. matt's go solution - Building from source

      +

      2. Go solution - Building from source

      Requirements: @@ -989,7 +398,7 @@ $ go version which should state something like: "go version go1.4.2"

      -Install matt's go solution from https://github.com/MDrollette/i2p-tools into $HOME/go: +Install Go solution from https://github.com/MDrollette/i2p-tools into $HOME/go: 

       $ go get github.com/MDrollette/i2p-tools
      @@ -1006,7 +415,7 @@ $ i2p-tools -

      21. matt's go solution - Run the reseed server

      +

      3. Go solution - Run the reseed server

       $ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb
@@ -1051,7 +460,7 @@ in order for your reseed server to be included in the standard I2P package.
 
 
 
-
      22. matt's go solution - Draft for startup script "seedserver"
      
+
      4. Go solution - Draft for startup script "seedserver"
      
 
 
      
 The reseed server should be started automatically, so you need a init.d or some sort of
@@ -1235,7 +644,7 @@ exit 0
 
 
 
-
      23. matt's go solution - reverse-proxy setup
      
+
      5. Go solution - reverse-proxy setup
      
 
 
      
 You can run i2p-tools also behind your normal web-server (reverse-proxy).
@@ -1290,11 +699,11 @@ and for X-Forwarded-For:
 
 
 
-
      24. matt's go solution - Convert existing Java keystore to crt- and pem-file
      
+
      6. Go solution - Convert existing Java keystore to crt- and pem-file
      
 
 
      
 This describes how to convert your existing Java keystore with your su3 signing key to a plain crt- and pem-file.
-This is only needed, when you already have a Java keystore and want to use matt's go solution.
+This is only needed, when you already have a Java keystore and want to use Go solution.
 If you create new keys+certs with matt's solution you can skip this chapter!
 
 
      
@@ -1340,4 +749,686 @@ openssl x509 -in ${file}.pem -out xxxxx_at_mail.i2p.crt
 ######################################################################################################
      + + + + +

      5. PHP solution - Not recommended

      + +

      1. Short overview

      + +
        +
      • permanent: run your I2P router +
      • once: generate a private and public key pair for signing the reseed files +
      • once: setup the PHP script on the web server +
      • once: setup a rewrite rule at web server (*.su3 --> su3.php) +
      • regularly: run the Unix shell script to generate up-to-date su3-files +
      • regularly: transfer su3-files to local /var/www/ or with (s)ftp to your remote web server +
      + + + +

      2. su3-file guidelines for reseeding

      + +

      +(From zzz.i2p) +

        +
      • The su3-file must be named "i2pseeds.su3" +
      • The file must be in the same directory as the routerinfos on the web server +
      • Router will first try to fetch (index url)/i2pseeds.su3; + if that fails it will fetch (index url) and then fetch the individual RI files, old-style +
      • Once a reseed from a host succeeds, it won't try any other URLs from that host + (either http or https, ignoring ports... ports are now implemented) +
      • RI files in the zip file (in the su3-file) must be at the "top level", + i.e. no directories in the zip file +
      • su3 content type must be RESEED (-c 3 or -c RESEED) +
      • su3 signature type should be RSA 4096 (-t 6 or -t RSA_SHA512_4096). + If you're very low on CPU power you could use a shorter key, but you only need to do the signing process once a day or so. + Any sig type will work, but RSA 4096 is the best in this case. +
      • Of course we must have your su3 signing public key checked in + under the same name as you are using in the signing process, + e.g. for you@mail.i2p the file name must be you_at_mail.i2p.crt, in the certificates/reseed/ directory +
      + + + +

      3. How to prepare your key pair for su3-files

      + +

      +( from zzz.i2p) +

        +
      • Details are posted here from zzz: zzz.i2p +
      • Who? All owner of a public reseed server. +
      • Why? su3 reseed files will be signed with your private key. +
      • This ensures a secure bootstrap for I2P routers. +
      • Corresponding public keys will be included in I2P router package. +
      + +

      +Example to create your key pair: +

      +	su - i2puser
+	I2P=/home/i2puser/i2p
+	cd $I2P
+	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File keygen -t RSA_SHA512_4096 backup_at_mail.i2p.crt keystore.ks backup@mail.i2p
+
      +

      +Short usage help: +

      +	SU3File keygen [-t type|code] publicKeyFile keystore.ks you@mail.i2p
+
      +

      +Get more help: +

      +	java -cp $I2P/lib/i2p.jar net.i2p.crypto.SU3File
+
      +

      +Provide a strong password for your private key. +In this example two new files will be created in the working folder: +

        +
      • backup_at_mail.i2p.crt will contain the public key +
      • keystore.ks is the Java keystore file and contains your private key +
      +

      +Backup and store public key, private key and your password! +Remember also the used key size/type when not using default RSA_SHA512_4096. +Send the public .crt key file to us, to include it into i2p/certificates/reseed/ +If you have mtn privs, you may check the (you)_at_mail.i2p.crt file directly into installer/resources/certificates/reseed . +The file name must be (email address used for signing).crt, with "@" replaced with "_at_". +There is no requirement that it be xxx@mail.i2p, any email is fine, or for that matter any identifier. + + + + +

      4. su3 server-side implementation

      + +

      +(from zzz.i2p) +This describes a mechanism for creating and distributing the RI in new su3 format. +It's independent from legacy way of doing (fetching dat-files) and can be used in parallel. +This idea doesn't need mysql, only some Unix shell tools and a simple web server with PHP works fine. + +

      +A requesting client gets ~75 RI packed into one zip, signed and converted to a su3-file. +Don't provide unlimited RI to one clients. +But don't try to keep track of million client IP's in a database, e.g think of ipv6. +Keep it simple: make a fix n:m one-direction matching: n*ip --> m*su3-file by modulo. +n is the unlimited IPv4+IPv6 address space, and m are e.g. 100 pre-calculated su3-files. +A client with one IP gets always the same su3-file, until the su3-file is updated or the client has a new IP. +A number of clients (n/m ratio) gets the same su3-file - the same set of RI, so m is subject to be monitored in I2P net grow. + +

      +Once or twice a week (or daily): pre-calculate ~100 new su3-files, each includes ~75 RI. +The RI are fetched from a well running I2P router's netdb directory. +Transfer the pre-calculate su3-files to your web server, e.g. by sftp or copy them locally to /var/www/su3/. +In the web server a PHP script will match one client IP to one of the 100 su3-files by hash+modulo. +This has the advantage to split su3-generation and publishing in web server . + +

      +Requirements for su3-file generation: +

        +
      • 24/7 running i2p-router with up to date netdb +
      • ziptool, e.g. "zip" (Debian/Ubuntu: sudo apt-get install zip) +
      • Unix shell: find, awk, cat, ... +
      • your reseed keys: e.g. backup_at_mail.i2p.crt + keystore.ks + password +
      +Requirements for web server : +
        +
      • PHP5 +
      • rewrite rule (*.su3 --> PHP) +
      + +The following solution for a public reseed server consists of three parts: +
        +
      • Unix shell script for cronjob +
      • PHP script +
      • url rewrite rule +
      +They are described on the following chapters in more detail. + + + + +

      5. Unix shell script for cronjob

      + +

      +This script pre-calculates n su3-files. +Requirements: Unix shell, Java, I2P, zip-tool, your private reseed signing key +Main Steps: +

      +# CONFIG
+# CHECK REQUIREMENT
+# CREATE index files from netdB: use only 66% and max. 10h old
+# CREATE zip files
+# CREATE su3 files
+# FINALIZE
+
      +

      +Please check and edit #CONFIG sections, please review code before use. +The resulting su3-files are placed in the "target" folder which can be changed in config section with "target". +Configure file permissions and file owner e.g. 'www-data' - see deactivated example lines. +The cronjob script runs ca. 10 seconds for generating 100 pre-calculated su3 files on a modern cpu. +The number of dat-files per su3 package is random. If you configure 75, it results in ca. 50...100 dat-files per su3-file. +The number of generated su3-files is random too, it depends on your netdb size and adapts automatically: +

        +
      • 1000 netdb entries: used for publishing: ~666, results in ~66 su3-files, each with ~75 dat-files +
      • 3000 netdb entries: used for publishing: ~1999, results in ~199 su3-files, each with ~75 dat-files +
      +

      +Only 66% of all RI from your netdb are used, netdb may be not older than 10h. +It is possible to separate cronjob script from PHP script: +Run the cronjob script on your I2P machine and then transfer the final su3-files via (s)ftp/ssh +to your web server from time to time. su3 file-size in this setup is between 50 and 100 KB per file. + + + + +

      6. Setup cronjob

      + +

      +Please add a cronjob, e.g. to run it every few days. +Add the shell script in crontab, e.g.: +

      +	crontab -e
+	23 59 * * * /usr/local/bin/cronjob_i2p.sh
+
      +

      +The hard limit for the su3-file age is 30 days. +Recommendation is to update the su3-files once every 1..10 days. + + + + +

      7. PHP script for web server

      + +

      +The su3.php script maps always one client IP to one pre-calculated su3-file. +Requirements: a web server with PHP5 +Main Steps: +

      +# CONFIG
+# HEALTH CHECK
+# COUNT su3 files
+# MAPPING Client IP to one SU3
+# PROVIDE SU3
+
      +

      +Please check and edit #CONFIG sections, please review code before use. + +

      +The date() function in the salt ensures a rotate once a day, even if su3-files are not updated daily. +To avoid scraping from attackers with big IPv4 subnet resources +(or even IPv6) some lower bytes of the client IP address are discarded: +

        +
      • IPv4: 4 byte --> 1 lowest byte +
      • IPv6: 16 bytes --> 8 lowest bytes +
      +Clients in the same "subnet" gets the same su3-file + +

      +A clients gets only different su3-file package in following circumstances: +

        +
      • when he gets a new IP (respecting the discarded bytes in the IPv4/v6 address) +
      • at 00:00 every date (date function in PHP) +
      • when the Unix cronjob updates the su3 files +
      + + + + + +

      8. url rewrite rule for web server

      + +

      +It is mandatory that clients does not have direct access to the su3-files at the web server. +Please activate a rewrite rule for su3-files in your web server pointing to the su3.php file: +

      +	*.su3 --> su3.php?file=$1
+
      + +

      +Apache in ".htaccess": +

      +	Options +FollowSymlinks
+	RewriteEngine On
+	RewriteRule ^(.*\.su3)$ /su3.php?file=$1 [L]
+
      + +

      +lighttpd in "/etc/lighttpd/lighttpd.conf": +

      +	server.modules += ( "mod_rewrite" )
+	url.rewrite-once = ( "^(.*\.su3)$" => "/su3.php?file=$1" )
+
      + +

      +We want only HTTPS accessible reseed server. +Sorted by best solution: +

        +
      • please deactivate plain HTTP, or +
      • use a redirect rule in your web server, or +
      • implement the redirect to HTTPS in the PHP code +
      + + + +

      9. Create self-signed ssl-certificate

      + +

      +How-to generate a new self-signed ssl-certificate for HTTPS/TLS with openssl. +Example command line in Debian/Ubuntu for your.server.com: + +

      +$ openssl req -x509 -nodes -days 1500 -newkey rsa:4096 -sha256 -keyout your.server.com.pem -out your.server.com.pem
+...
+Country Name (2 letter code) [AU]:UK
+State or Province Name (full name) [Some-State]:your.server.com
+Locality Name (eg, city) []:your.server.com
+Organization Name (eg, company) [Internet Widgits Pty Ltd]:your.server.com
+Organizational Unit Name (eg, section) []:your.server.com
+Common Name (e.g. server FQDN or YOUR name) []:your.server.com
+Email Address []:your.server.com
+
      + +

      +The result is stored in "your.server.com.pem" file + +

      +Remarks: +

        +
      • Please fill out all fields, don't use blanks +
      • rsa:4096 - key size, do not use 1024, you can use 2048 bits too, impact on server cpu +
      • use rsa, not ecdsa (ecdsa will break currently RetHat users) +
      • Optional: +Instead of RSA key and signature use a EC 384 key and signature, example: +
         
+f=your.server.com
+openssl ecparam -name secp384r1 -genkey -out $f.key
+openssl req -new -x509 -key $f.key -out ${f}.crt -days 2000 -sha512
+cat $f.key $f.crt > $f.pem
+
        +This results in a EC 384 bit key with SHA512withECDSA signature. +
      • days 1500 - validity period in days (choose at will between 1100-2000 (3-5 years)) +
      • sha256 - important, without this option openssl currently uses weak sha1 by default +
      • Do NOT reveal the private .pem key file to anyone - keep it save - keep a backup. +
      + +

      +Next step: +

        +Open the created pem-file with a simple text editor. +You see the section with the private key and the section with the public key. +Copy the public section (starting with -----BEGIN CERTIFICATE-----) to another new file +and save the new file as your.server.com.crt file +
      + +

      +Send this to us - the .crt file with the public key section will we included in every I2P router. +The .pem file with your private key is only for you and your web server. + + + + +

      10. Seamless ssl-certificate exchange

      + +

      +The update/exchange of an already existing self-signed certificates has to be correct timed +on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange +will not be seamless possible and will have very bad impact on many clients: reseed won't work for them. + +

      +To avoid this issue and make the exchange as smooth as possible follow these simple steps: + +

        +
      1. generate a new ssl-certificate NOW, but do NOT implement it on server +
      2. send the new ssl-certificate to us to perform a roll-out towards clients NOW +
      3. WAIT some month, e.g. 3-4 i2p-releases +
      4. new ssl-certificate is now hopefully present on many clients (in parallel to the current/old one) +
      5. THEN exchange the ssl-certificate on server +
      + +

      +This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g. +server.com.crt and server.com2.crt + + + + +

      11. reseed server domain/url/port exchange

      + + +

      +You are already operating a reseed server but want to change your domain/url/port? +To make the exchange as smooth as possible for many clients please follow these steps if possible: + +

        +
      1. Setup an additional reseed instance at the new domain/url/port +
      2. we include the new url into I2P source NOW and delete the old url NOW +
      3. both of your reseed instances have to run some time in parallel +
      4. WAIT some month, e.g. 3-4 i2p-releases +
      5. new url is now hopefully present on many clients +
      6. THEN shutdown the old reseed instance +
      + + + +

      12. Tests

      + +

      +Some simple pre-test: test the website and fetch +

      +	wget --user-agent="Wget/1.11.4" -O /tmp/test.su3 --no-check-certificate https://your-server.com:PORT/i2pseeds.su3
+
      +Replace "PORT" with default 443 or your chosen server setting. +Inspect the fetched file.: +Some simple pre-test: test the website and fetch +
      +	zipinfo -z /tmp/test.su3
+
      + +

      +Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt" +which contains the path to your local public ssl-certificate to check also your ssl-certificate chain. + +

      +Everything ok: +

        +
      • ssl-certificate chain valid? +
      • The su3-files can be downloaded? +
      • contains > 50 dat-files? +
      • and is always the same for one client-IP? +
      • other client-IP's gets another file? +
      • Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ? +
      + +

      +Do a real reseed test on *another* I2P router machine: +

        +
      • include manually new ssl-certificate into i2p installation: ~/i2p/certificates/ssl/ +
      • include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/ +
      • http://localhost:7657/configreseed --> remove all reseed hosts +
      • add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3" +
      • Save and Shutdown router. +
      • clear netdb: empty folder ./i2p/netDb. +
      • Restart I2P and watch the I2P router log: +
        +2014/10/13 23:01:02 | Reseed start
+2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
+2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
+2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
+2014/10/13 23:01:06 | Reseed complete, xx received
+
        +
      + + + + +

      13. Contact reseed maintainer

      + +

      +Contact us per email backup@mail.i2p (fallback is killyourtv@mail.i2p or the reseed section at zzz's forum) +Provide us details about the new +

        +
      • reseed website url, +
      • public part of ssl-certificate +
      • public su3-key +
      • your contact email +
      +

      +Feel free to contact backup@mail.i2p in case of questions or problems or post your question at zzz's forum in the reseed section. + + + + +

      14. Script - cronjob_i2p.sh

      +
      +###############################################################################
+#!/bin/sh
+version="v5"
+
+
+# CONFIG
+I2P="${HOME}/i2p"			# i2p installation directory
+source="${HOME}/.i2p/netDb"		# valid netdb
+target="${HOME}/i2pseeds.su3"		# location for the final su3-files
+
+key_keystore="${I2P}/keystore.ks"	# your private su3 reseed key
+key_password="secret"			# your password for private key of keystore.ks
+key_email=yourmail@mail.i2p		# your email id for reseeding
+key_type=RSA_SHA512_4096		# your key size/type for reseeding (DO NOT EDIT, unless you know why)
+
+tool_zip="/usr/bin/zip"			# install a "zip" tool: sudo apt-get install zip
+tool_i2p="$I2P/lib/i2p.jar"		# should be already there
+
+
+# CONFIG (DO NOT EDIT)
+ri_seed=75				# average number ri per su3-file (DO NOT EDIT)
+stamp=$(date +%s)			# unique id (DO NOT EDIT)
+target_tmp="/tmp/i2pseeds.${stamp}.tmp"	# temp folder with unique id (DO NOT EDIT)
+
+
+# CLEAN /tmp/i2pseeds.*
+find /tmp -type d -iname 'i2pseeds.*.tmp' -exec rm -rf {} \;
+mkdir --parents "${target_tmp}"
+
+
+# CHECK REQUIREMENT
+[ ! -d "${I2P}" ]          && echo "ERROR1: path not found: ${I2P}"          && exit 1
+[ ! -d "${source}" ]       && echo "ERROR2: path not found: ${source}"       && exit 1
+[ ! -d "${target_tmp}" ]   && echo "ERROR3: path not found: ${target_tmp}"   && exit 1
+[ ! -x "${tool_zip}" ]     && echo "ERROR4: command not found: ${tool_zip}"  && exit 1
+[ ! -f "${tool_i2p}" ]     && echo "ERROR5: file not found: ${tool_i2p}"     && exit 1
+[ ! -f "${key_keystore}" ] && echo "ERROR6: file not found: ${key_keystore}" && exit 1
+
+
+# CREATE index-files from netdB: use only 66% and max. 10h old
+find "${source}" -type f -mmin -600 -name 'routerInfo-*.dat' | awk -v ri_seed="${ri_seed}" -v target_tmp="${target_tmp}" '
+	BEGIN { ri_all=0; }
+	{	data[ri_all++]=$0; }
+	END {	srand();
+		ri_use=ri_all*0.6666;
+		ri_su3=int(ri_use/10);
+		stepy=ri_use/ri_all;
+		stepx=ri_seed/ri_use;
+		for (y=0;y<ri_all; y++) if (rand()<=stepy) {
+			for (x=0; x<ri_su3; x++) if (rand()<=stepx) {
+				file=target_tmp"/"x".index";
+				print data[y] >> file
+			}
+		}
+	}'
+
+
+# CREATE zip-files from index-files
+find "${target_tmp}" -type f -name '*.index' | sort | while read i; do
+	"${tool_zip}" --update --quiet --junk-paths "${target_tmp}/$(basename "$i" .index)" -@ < "$i"
+done
+
+
+# CREATE su3-files from zip-files
+echo "${key_password}" | java -cp "${tool_i2p}" net.i2p.crypto.SU3File bulksign -c RESEED -t "${key_type}" "${target_tmp}" "${key_keystore}" "${stamp}" "${key_email}"
+
+
+# REMOVE index-files and zip-files
+find "${target_tmp}" -type f -name '*.index' -exec rm -f "{}" \;
+find "${target_tmp}" -type f -name '*.zip'   -exec rm -f "{}" \;
+
+
+# FINAL CHECK number su3-files
+c_su3=$(find "${target_tmp}" -type f -mmin -600 -name '*.su3' | wc -l)
+[ "${c_su3}" -lt 25 ] && echo "ERROR7: less than 25 su3 files found: ${c_su3}" && rm -Rf "${target_tmp}" && exit 1
+echo "Created: $target_tmp ${c_su3} x${ri_seed}"
+
+
+# MOVE su3-files to target
+chmod 755 "${target_tmp}" -R
+rm -fr "${target}.old"
+mv -f  "${target}"     "${target}.old"
+mv -f  "${target_tmp}" "${target}"
+rm -fr "${target_tmp}"
+
+
+# EXIT
+echo      "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
+logger -t "$(basename "$0")" "${version} ${target} ${c_su3} x${ri_seed}"
+exit 0
+###############################################################################
+
      + + + +

      15. Script - su3.php

      +
      +###############################################################################
+<?php
+$version="v5";
+
+
+# CONFIG
+$path_su3="/home/i2p/i2pseeds.su3";		# path to pre-calculated su3 files
+$salt="change_to_something";			# change salt to something random
+$salt=$salt . date("Y-m-d");			# date() ensures a rotate once a day, even if su3 are not updated daily (DO NOT EDIT)
+$file_su3  = "i2pseeds.su3";			# static (DO NOT EDIT)
+$user_agent= "Wget/1.11.4";			# static (DO NOT EDIT)
+
+
+# INSIDE i2p-net ? If yes: convert DESTB32 into pseudo IPv6 as valid REMOTE_ADDR
+if (	$_SERVER["REMOTE_ADDR"]=="127.0.0.1"
+	&& isset($_SERVER["HTTP_X_I2P_DESTB32"])
+  ) {	$_SERVER["REMOTE_ADDR"]=inet_ntop(substr(md5($_SERVER["HTTP_X_I2P_DESTB32"]),0,16)); }
+
+
+# HEALTH CHECK 1
+if (	!isset($_SERVER['HTTP_USER_AGENT'])
+	|| !isset($_SERVER['REMOTE_ADDR'])
+	|| !isset($_GET['file'])
+    ) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+
+
+# COUNT su3 files
+$count_su3 = count(glob($path_su3."/*.su3"));
+
+
+# HEALTH CHECK 2
+if (	empty($_SERVER['HTTP_USER_AGENT'])
+	|| empty($_SERVER['REMOTE_ADDR'])
+	|| empty($_GET['file'])
+	|| (strcmp(basename($_GET['file']), $file_su3) != 0)
+	|| (strcmp($_SERVER['HTTP_USER_AGENT'], $user_agent) != 0)
+	|| !filter_var($_SERVER['REMOTE_ADDR'], FILTER_VALIDATE_IP)
+	|| $count_su3<1
+    ) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+
+
+# MAPPING Client IP to one su3-file
+$remote_id = inet_pton($_SERVER['REMOTE_ADDR']);
+$shrink=3; if (strlen($remote_id)>8) { $shrink=8; };
+$remote_id = abs(crc32(md5(substr($remote_id,0,$shrink).$salt))) % $count_su3;
+$file_id = $path_su3."/".$remote_id.".su3";
+
+
+# HEALTH CHECK 3
+if (!file_exists($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+
+
+# PROVIDE su3-file
+header('Content-Description: File Transfer');
+header("Content-Type: application/zip");
+header('Content-Transfer-Encoding: binary');
+header('Content-Length: '.filesize($file_id));
+header('Content-Disposition: attachment; filename='.$file_su3);
+ob_clean(); flush();
+if (!readfile($file_id)) { header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found", true, 404); die(); }
+exit;
+?>
+###############################################################################
+
      + + + +

      16. Optional - setup a manual reseed method

      +

      +For some users the automated reseeding may not work. +This is an alternate way for users to get a valid reseed file with a normal web-browser, +e.g. from another machine or maybe a friend. It is secured by a captcha to prevent abuse. + +

      +With this optional code users can visit https://your.reseedserver.com/reseed.php +with any web-browser to download a su3-file after they solved the captcha. + +

      +Since 0.9.18-9 I2P has support to use reseed files from other sources: +http://localhost:7657/configreseed + +

      +Visit https://geti2p.net/en/faq#manual_reseed to read how it works for users and see some example url's. +[NOT DONE YET: read here: zzz.i2p +or test here anonymously: reseed.i2p] + +

      +The changes for an exiting reseed server with the previous setup are simple: +

        +
      • use the latest su3.php from above (minimal version 5, only minor changes, no change of logic). +
      • add the new reseed.php to your /var/www folder, next to to su3.php +
      • install php5-gd (restart of PHP processes may be necessary) +
      • get Securimage php-code from https://www.phpcaptcha.org/ +
      + +

      +Quote from https://www.phpcaptcha.org (2015-03): +"Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect +forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots. +It can run on most any web server as long as you have PHP installed, and GD support within PHP. +Securimage does everything from generating the CAPTCHA images to validating the typed code." + +

      +Short overview about installing Securimage: +

        +
      1. download at https://www.phpcaptcha.org/download/ +
      2. extract to /var/www/securimage +
      3. download and extract the "Test Script" (securimage_test.php) from the same url +
      4. test your server and visit https://.../securimage_test.php with your browser +
      +

      +The "Test Script" verifies your ability to run and display the captcha code, and can be deleted after the test. + +

      +The reseed.php contains only the captcha generation and verification of the users input. It is based on the +Quickstart Guide from Securimage. When the user solved the captcha, reseed.php sets two http variables and +then includes the external su3.php to start the su3-file download. + +

      +The name "reseed.php" is not fixed, you can name it unremarkable/unobtrusive as you like, +enter.php start.php go.php... +but you have to stick with it, when it is published :-) + +

      +reseed.php: +

      +################################################################################################
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><body>
+<?php
+session_start();
+include_once $_SERVER['DOCUMENT_ROOT'] . '/securimage/securimage.php';
+$securimage = new Securimage();
+
+if (!isset($_POST['captcha_code']) || $securimage->check($_POST['captcha_code']) == false) {?>
+	<form method="post" action="<?php echo(basename($_SERVER['PHP_SELF'])); ?>">
+	<img id="captcha" src="/securimage/securimage_show.php" alt="CAPTCHA Image" />
+	<p>Enter Code: <input type="text" name="captcha_code" size="10" maxlength="6" />
+	<input type="submit" value="Check Code" />
+	</form>
+<?php } else {
+	$_SERVER['HTTP_USER_AGENT']="Wget/1.11.4";
+	$_GET['file']="i2pseeds.su3";
+	include_once $_SERVER['DOCUMENT_ROOT'] . "/su3.php";
+} ?>
+</body></html>
+################################################################################################
+
      + + + + {% endblock %} From 9bca5bf981538dd51e8528063b3cec99d1c43dfa Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 2 Feb 2016 14:04:14 +0000 Subject: [PATCH 095/114] bump date --- i2p2www/pages/site/get-involved/guides/reseed.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index ebe9951a..b2320304 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{{ _('How to Set up a Reseed Server') }}{% endblock %} -{% block lastupdated %}{% trans %}December 2015{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} {% block content %}

      {% trans %}Overview{% endtrans %}

      From bf554525b9ba363e83c2dc7ca9d3b47df6816e00 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 2 Feb 2016 14:26:55 +0000 Subject: [PATCH 096/114] add reserved types --- .../pages/site/docs/spec/common-structures.html | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/common-structures.html b/i2p2www/pages/site/docs/spec/common-structures.html index 2464ede6..8f25f9fa 100644 --- a/i2p2www/pages/site/docs/spec/common-structures.html +++ b/i2p2www/pages/site/docs/spec/common-structures.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Common structures Specification{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} {% block accuratefor %}0.9.24{% endblock %} {% block content_nav %} @@ -449,13 +449,22 @@ The defined Signing Key types are: + + + +
      Recent Router Identities and Destinations
      EdDSA_SHA512_Ed25519ph8320.9.25 Offline only; never used in Key Certificates for Router Identities or Destinations
      reserved65280 - 65534Reserved for experimental use
      reserved65535Reserved for future expansion

      The defined Crypto Public Key types are:

      - - + + + + + + +
      TypeType CodeTotal Public Key Length
      ElGamal0256
      TypeType CodeTotal Public Key Length{% trans %}Since{% endtrans %}{% trans %}Usage{% endtrans %}
      ElGamal02560.9.12All Router Identities and Destinations
      reserved65280 - 65534Reserved for experimental use
      reserved65535Reserved for future expansion

      From cf529a7b9a7bc551bc884dca03b27ecc2c7c510f Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 2 Feb 2016 14:28:29 +0000 Subject: [PATCH 097/114] roadmap update --- i2p2www/pages/site/get-involved/roadmap.html | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/get-involved/roadmap.html b/i2p2www/pages/site/get-involved/roadmap.html index 6dea0ffa..2ea44019 100644 --- a/i2p2www/pages/site/get-involved/roadmap.html +++ b/i2p2www/pages/site/get-involved/roadmap.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Roadmap') }}{% endblock %} -{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} {% block content %}

      @@ -20,7 +20,7 @@ Our normal release cycle is 6-10 weeks.

      0.9.24

      -

      Target release date: Week of January 25, 2016

      +

      Released: January 27, 2016

      • SAM v3.2
      • @@ -38,6 +38,8 @@ Unit test improvements
      • Complete transition to Ed25519 signatures for most routers
      • +Tunnel Bloom filter fixes +
      • Bug fixes, translation updates, geoip updates
      @@ -55,7 +57,13 @@ SAM v3.3
    10. Sybil tool enhancements
    11. +QR codes and identicons
    12. +Crypto enhancements +
    13. +Router family configuration UI +
    14. +Custom icons for plugins
    15. Bug fixes, translation updates, geoip updates
      16. @@ -72,6 +80,7 @@ Sybil tool migration to automatic?
    16. Streaming improvements
    17. +Certificate revocations (CRL) ?
    20. From f49a290f7e8ab0af1f11f1038ccaf548c70c3470 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 6 Feb 2016 14:03:38 +0000 Subject: [PATCH 098/114] Plugins: Document new icon-code configuration for 0.9.25 (ticket #1550, thx cacapo!) I2CP: Reserve codes for experimental protocols Roadmap: Push out GMP 6 to 0.9.25 --- i2p2www/pages/site/docs/protocol/i2cp.html | 9 +++++++-- i2p2www/pages/site/docs/spec/plugin.html | 10 +++++++--- i2p2www/pages/site/get-involved/roadmap.html | 10 +++++----- 3 files changed, 19 insertions(+), 10 deletions(-) diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html index e465d4d8..ae46e284 100644 --- a/i2p2www/pages/site/docs/protocol/i2cp.html +++ b/i2p2www/pages/site/docs/protocol/i2cp.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2CP{% endblock %} -{% block lastupdated %}{% trans %}December 2014{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.17{% endblock %} +{% block lastupdated %}{% trans %}Fegruary 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.24{% endblock %} {% block content %}

      {% trans -%} The I2P Client Protocol (I2CP) exposes a strong separation of concerns between @@ -709,6 +709,11 @@ turns the gzip effort setting to 0, which may save a little CPU. +

      +Note: I2P protocol numbers 224-254 are reserved for experimental protocols. +I2P protocol number 255 is reserved for future expansion. +

      +

      {% trans -%} Data integrity is verified with the standard gzip CRC-32 as specified by RFC 1952. diff --git a/i2p2www/pages/site/docs/spec/plugin.html b/i2p2www/pages/site/docs/spec/plugin.html index fc78ec7e..037fe41d 100644 --- a/i2p2www/pages/site/docs/spec/plugin.html +++ b/i2p2www/pages/site/docs/spec/plugin.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2P Plugin Specification{% endblock %} -{% block lastupdated %}January 2016{% endblock %} -{% block accuratefor %}0.9.24{% endblock %} +{% block lastupdated %}February 2016{% endblock %} +{% block accuratefor %}0.9.25{% endblock %} {% block content %}

      Overview

      @@ -129,13 +129,17 @@ The first three must be identical to those in the installed plugin for an update - The following optional property may be used to add a custom icon on the console: + The following optional properties may be used to add a custom icon on the console: 

       
 	console-icon (supported as of 0.9.20) Only for webapps.
 		A path within the webapp to a 32x32 image, e.g. /icon.png
                 Applies to all webapps in the plugin.
 
+	icon-code (supported as of 0.9.25) 
+		Provides a console icon for plugins without web resources.
+		A B64 string produced by calling 'net.i2p.data.Base64 encode FILE' 
+		on a 32x32 image png file.
      The following properties are used by the plugin installer: diff --git a/i2p2www/pages/site/get-involved/roadmap.html b/i2p2www/pages/site/get-involved/roadmap.html index 2ea44019..7fb474aa 100644 --- a/i2p2www/pages/site/get-involved/roadmap.html +++ b/i2p2www/pages/site/get-involved/roadmap.html @@ -47,23 +47,21 @@ Bug fixes, translation updates, geoip updates

      0.9.25

      -

      Target release date: March 2016

      +

      Target release date: mid-to-late March 2016

      • Wrapper 3.5.27
      • -GMP 6.0 -
      • SAM v3.3
      • Sybil tool enhancements
      • QR codes and identicons
      • -Crypto enhancements +Crypto enhancements and speedups
      • Router family configuration UI
      • -Custom icons for plugins +Custom icons for non-webapp plugins
      • Bug fixes, translation updates, geoip updates
      @@ -76,6 +74,8 @@ Bug fixes, translation updates, geoip updates
      • New subscription protocol, addressbook support
      • +GMP 6.0 +
      • Sybil tool migration to automatic?
      • Streaming improvements From b5bea6b164ad1bb31dd8577b7c11497b468c4c7b Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 6 Feb 2016 19:31:23 +0000 Subject: [PATCH 099/114] SAM v3.3 preliminary spec --- i2p2www/pages/site/docs/api/samv3.html | 143 +++++++++++++++++++++++-- 1 file changed, 136 insertions(+), 7 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 4384ba52..3f1a5c73 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}SAM V3{% endblock %} -{% block lastupdated %}January 2016{% endblock %} -{% block accuratefor %}0.9.24{% endblock %} +{% block lastupdated %}February 2016{% endblock %} +{% block accuratefor %}0.9.25{% endblock %} {% block content %}

        Specified below is a simple client protocol for interacting with I2P.

        @@ -104,9 +104,9 @@ Version 3.2 was introduced in I2P release 0.9.24. Version 3.3 is not yet implemented, and the changes listed below are preliminary. Scheduled for I2P release 0.9.25.
          -
        • The same session ID may be used for streams, datagrams, and raw simultaneously. +
        • The same session may be used for streams, datagrams, and raw simultaneously. Incoming packets and streams will be routed based on I2P protocol and to-port. -
        • STREAM ACCEPT now supports option TO_PORT=nnnn to accept connections on that I2P port only + See the MASTER section below.
        • DATAGRAM SEND and RAW SEND now supports options SEND_TAGS=nnn, TAG_THRESHOLD=nnn, EXPIRES=nnnnnnn, and SEND_LEASESET=true|false. These will be passed to I2CP if supported. See the I2CP specification for details. Support by the SAM server is optional, it will ignore these options if unsupported. @@ -331,7 +331,7 @@ received through other forms are answered with an error message) : [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 [HEADER={true,false}] # SAM 3.2 or higher only, for STYLE=RAW only, default false - [option=value]* + [option=value]* # I2CP and streaming options

          @@ -367,7 +367,7 @@ be a way to provide an override, e.g. i2cp.tcp.host=localhost and i2cp.tcp.port=7654).

          -

          Session Creation Response

          +

          Session Creation Response

          After receiving the session create message, the SAM bridge will reply with a session status message, as follows: @@ -799,7 +799,7 @@ CREATE command with PORT and HOST options: [FROM_PORT=nnn] # SAM 3.2 or higher only, default 0 [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 - [option=value]* + [option=value]* # I2CP options

          @@ -952,6 +952,135 @@ sent to the most recently created DATAGRAM- or RAW-style session, as appropriate. Support for the ID parameter may be added in a future release. +

          MASTER Sessions (V3.3 and higher)

          + +

          +Version 3.3 is scheduled for I2P release 0.9.25. +The specification below is preliminary and subject to change. +

          + +

          +SAM v3.3 adds support for running streaming, datagrams, and raw subsessions on the same +master session, and for running multiple subsessions of the same style. +All subsession traffic uses a single destination, or set of tunnels. +Routing of traffic from I2P is based on the port and protocol options for the subsessions. +

          + +

          +To create multiplexed subsessions, you must create a master session +and then add subsessions to the master session. +Each subsession must have a unique id and a unique listen protocol and port. +Subsessions may also be removed from the master session. +

          + +

          Creating a MASTER Session

          + +
          +->  SESSION CREATE 
+          STYLE=MASTER
+          ID=$nickname
+          DESTINATION={$privkey,TRANSIENT}
+          [option=value]*                      # I2CP and streaming options
+
          + +

          +The SAM bridge will respond with success or failure as in the response to a standard SESSION CREATE. +

          +Do not set the PORT, HOST, FROM_PORT, TO_PORT, PROTOCOL, LISTEN_PORT, LISTEN_PROTOCOL, or HEADER options on a master session. +You may not send any data on a MASTER session ID or on the control socket. All commands such as +STREAM CONNECT, DATAGRAM SEND, etc. must use the subsession ID on a separate socket. +

          +The MASTER session connects to the router and builds tunnels. When the SAM bridge responds, +tunnels have been built and the session is ready for subsessions to be added. +All I2CP options pertaining to tunnel parameters such as length, quantity, and nickname must +be provided in the master's SESSION CREATE. +

          +All utility commands are supported on a master session. +

          +When the master session is closed, all subsessions get closed also. +

          + + +

          Creating a Subsession

          + +

          +Using the same control socket on which the MASTER session was created: +

          + +
          +->  SESSION ADD
+          STYLE={STREAM,DATAGRAM,RAW}
+          ID=$nickname                         # must be unique
+          [PORT=$port]                         # Required for DATAGRAM and RAW, invalid for STREAM
+          [HOST=$host]                         # Optional for DATAGRAM and RAW, invalid for STREAM
+          [FROM_PORT=nnn]                      # For outbound traffic, default 0
+          [TO_PORT=nnn]                        # For outbound traffic, default 0
+          [PROTOCOL=nnn]                       # For outbound traffic for STYLE=RAW only, default 18
+          [LISTEN_PORT=nnn]                    # For inbound traffic, default is the FROM_PORT value.
+                                               # For STYLE=STREAM, only the FROM_PORT value or 0 is allowed.
+          [LISTEN_PROTOCOL=nnn]                # For inbound traffic for STYLE=RAW only.
+                                               # Default is the PROTOCOL value; 6 (streaming) is disallowed
+          [HEADER={true,false}]                # For STYLE=RAW only, default false
+          [option=value]*                      # I2CP and streaming options
+
          + +

          +The SAM bridge will respond with success or failure as in the response to a standard SESSION CREATE. +As the tunnels were already built in the master SESSION CREATE, the SAM bridge should respond immediately. +

          +Do not set the DESTINATION option on a SESSION ADD. +The subsession will use the destination specified in the master session. +All subsessions must be added on the control socket, i.e. the same connection that you created the master session on. +

          +Multiple subsessions must have options sufficiently unique +that incoming data can be routed correctly. +In particular, multiple sessions of the same style must have +different LISTEN_PORT options (and/or LISTEN_PROTOCOL, for RAW only). +A SESSION ADD with listen port and protocol that duplicates an existing subsession will result in an error. +

          +The LISTEN_PORT is the local I2P port, i.e. the receive (TO) port for +incoming data. +If the LISTEN_PORT is not specified, the FROM_PORT value will be used. +If the LISTEN_PORT and FROM_PORT are not specified, incoming routing will be based on +STYLE and PROTOCOL alone. +For LISTEN_PORT and LISTEN_PROTOCOL, 0 means any value, that is, a wildcard. +If both LISTEN_PORT and LISTEN_PROTOCOL are 0, +this subsession will be the default for incoming traffic that does not get routed to another subsession. +Incoming streaming traffic (protocol 6) will never be routed to a RAW subsession, even if its LISTEN_PROTCOL is 0. +A RAW subsession may not set a LISTEN_PROTOCOL of 6. +If there is no default or subsession that matching the protocol and port of incoming traffic, that data will be dropped. +

          +Use the subsession ID, not the master session ID, for sending and receiving data. +All commands such as STREAM CONNECT, DATAGRAM SEND, etc. +must use the subsession ID. + +

          +All utility commands are supported on a master session or subsession. +v1/v2 datagram/raw sending/receiving are not supported on a master session or on subsessions. +

          + + +

          Stopping a Subsession

          +

          +Using the same control socket on which the MASTER session was created: +

          + +
          +->  SESSION REMOVE
+          ID=$nickname
+
          + +

          +This removes a subsession from the master session. +Do not set any other options on a SESSION REMOVE. +Subsessions must be removed on the control socket, i.e. the same connection that you created the master session on. +After a subsession is removed, it is closed and may not be used to send or receive data. +

          +The SAM bridge will respond with success or failure as in the response to a standard SESSION CREATE. +

          + + +

          SAM Utility Commands

          From 16c0993c2fff766aebf0cd2e8aff8f105be04fdd Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 6 Feb 2016 19:53:25 +0000 Subject: [PATCH 100/114] Java 7 now required --- i2p2www/pages/downloads/list.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index ddf13732..0b11af16 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -25,13 +25,13 @@ icedtea='http://icedtea.classpath.org/wiki/Main_Page', arm8='http://www.oracle.com/technetwork/java/javase/downloads/jdk8-arm-downloads-2187472.html', ibmsdk7='http://www.ibm.com/developerworks/java/jdk/linux/download.html', detectjre='https://java.com/en/download/installed.jsp?detect=jre&try=1' %} -Java Runtime 1.6 or higher. +Java Runtime Version 7 or higher. (Oracle, OpenJDK, or IcedTea Java Version 7 or 8 recommended, -except Raspberry Pi: JDK 8 for ARM, -PowerPC: IBM SDK 7) +except Raspberry Pi: Oracle JDK 8 for ARM, +PowerPC: IBM Java SE 7 or 8)
          Determine your installed Java version here or type java -version at your command prompt. From 1d7291799d6dfe7bfa179ac4587894ef5ef17877 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 6 Feb 2016 20:05:06 +0000 Subject: [PATCH 101/114] cleanups --- i2p2www/pages/site/docs/api/samv3.html | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 3f1a5c73..07bfcc60 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -118,15 +118,15 @@ Scheduled for I2P release 0.9.25.

          Version 3 Protocol

          Simple Anonymous Messaging (SAM version 3.0) Specification Overview

          -Client application talks to SAM bridge, which deals with +The client application talks to the SAM bridge, which deals with all of the I2P functionality (using the streaming -lib for virtual streams, or I2CP directly for async messages). +library for virtual streams, or I2CP directly for datagrams).

          -The client<-->SAM bridge communication may unencrypted or unauthenticated. +By default, the client<-->SAM bridge communication is unencrypted and unauthenticated. The SAM bridge may support SSL/TLS connections; configuration and implementation details are outside the scope of this specification. -As of SAM 3.2, optional authentication in the handshake is specified +As of SAM 3.2, optional authentication user/password parameters are supported in the initial handshake and may be required by the bridge..

          @@ -142,7 +142,8 @@ I2P communications can take three distinct forms: I2P communications are supported by I2P sessions, and each I2P session is bound to an address (called destination). An I2P session is associated with one of the three types above, and cannot carry -communications of another type. +communications of another type, +unless using MASTER sessions.

          @@ -971,6 +972,14 @@ To create multiplexed subsessions, you must create a master session and then add subsessions to the master session. Each subsession must have a unique id and a unique listen protocol and port. Subsessions may also be removed from the master session. + +

          +With a MASTER session and a combination of subsessions, a SAM client +may support multiple applications, or a single sophisticated application +using a variety of protcols, on a single set of tunnels. +For example, a bittorrent client could set up a streaming subsession +for peer-to-peer connections, together with datagram and raw subsessions +for DHT communication.

          Creating a MASTER Session

          From e0a9ab3f10145c0b48f764a91faa01ecf42c3558 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 7 Feb 2016 14:23:04 +0000 Subject: [PATCH 102/114] update research page --- i2p2www/pages/site/research/index.html | 35 ++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/i2p2www/pages/site/research/index.html b/i2p2www/pages/site/research/index.html index e4cf2601..3d24e055 100644 --- a/i2p2www/pages/site/research/index.html +++ b/i2p2www/pages/site/research/index.html @@ -1,10 +1,18 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Academic Research') }}{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} {% block content %}

          {% trans -%} Academic research and analysis of I2P is an important part of ensuring that the software and network performs as expected and is safe for users in hostile environments. {%- endtrans %}

          +

          {% trans torg='https://blog.torproject.org/blog/ethical-tor-research-guidelines' %} +Recent events have prompted anonymity projects to provide specific guidelines +for responsible research. +We endorse the Tor Ethical Research Guidelines and incorporate them here. +Please follow the Tor guidelines when researching I2P as well. +{% endtrans %}

          +

          {% trans anonbib='http://freehaven.net/anonbib/' %} There is a large research community investigating a wide range of aspects of anonymity. For a current and comprehensive list of relevant papers, see the @@ -19,6 +27,10 @@ original research. A list of known published papers about I2P is available here. {%- endtrans %}

          +

          {% trans torr='https://research.torproject.org/' %} +See also the Tor Research Home Page for general guidance and links. +{% endtrans %}

          +

          {{ _('Testing Attacks on I2P') }}

          {% trans -%} @@ -43,4 +55,27 @@ Additionally, I2P can be started in a virtual network mode. This mode disables a

          {% trans contact=site_url('contact') -%} If you are planning on conducting research on the live I2P network, please contact us before you commence your testing. While we do not discourage researchers from responsibly testing their ideas on the live network, if an attack becomes apparent and we don't have any line of communication then we will end up taking countermeasures which could interfere with the test. {%- endtrans %}

          + + +

          {{ _('Router Family Configuration') }}

          + +

          {% trans -%} +As of release 0.9.25, I2P supports a router family configuration. +This provides researchers who run multiple routers with the means to publicly identify those routers. +In turn, this helps the I2P project understand that these routers are not running an attack on the network. +It also will prevent other routers from including multiple routers of the family in a single tunnel, +which could lead to deanonymization. +Routers that appear to be colluding but do not have a declared family may be assumed to +be an attack on the network, and may be blocked. +The best way to ensure the success of your research project is to work with us. +{%- endtrans %}

          + +

          {% trans -%} +A router family shares a private key so that participation in the family cannot be spoofed. +To configure a router family, click on the 'I2P Internals' link in the router console, +and then on the 'Family' tab. +Follow the instructions there to generate the private key for the first router in the family. +Then, export the key from that router, and import it to other members of the family. +{%- endtrans %}

          + {% endblock %} From b5d3b755ac56d250ad36374ef2bfd997e2cdda95 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 7 Feb 2016 19:07:27 +0000 Subject: [PATCH 103/114] SAM v3.3 add tag options --- i2p2www/pages/site/docs/api/samv3.html | 40 ++++++++++++++++++++------ 1 file changed, 31 insertions(+), 9 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 07bfcc60..6aac5398 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -107,9 +107,7 @@ Scheduled for I2P release 0.9.25.
        • The same session may be used for streams, datagrams, and raw simultaneously. Incoming packets and streams will be routed based on I2P protocol and to-port. See the MASTER section below. -
        • DATAGRAM SEND and RAW SEND now supports options SEND_TAGS=nnn, TAG_THRESHOLD=nnn, EXPIRES=nnnnnnn, and SEND_LEASESET=true|false. - These will be passed to I2CP if supported. See the I2CP specification for details. - Support by the SAM server is optional, it will ignore these options if unsupported. +
        • DATAGRAM SEND and RAW SEND now support options SEND_TAGS, TAG_THRESHOLD, EXPIRES, and SEND_LEASESET.

        @@ -332,6 +330,7 @@ received through other forms are answered with an error message) : [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 [HEADER={true,false}] # SAM 3.2 or higher only, for STYLE=RAW only, default false + [v3.3 datagram and raw options] # see below [option=value]* # I2CP and streaming options @@ -701,7 +700,7 @@ soon as the "forwarding" socket is closed. -

        SAM Repliable Datagrams : Sending a Datagram

        +

        SAM Datagrams : Sending Repliable or Raw Datagrams

        While I2P doesn't inherently contain a FROM address, for ease of use an additional layer is provided as repliable datagrams - unordered @@ -716,8 +715,8 @@ size is approximately 11 KB. Reliability is inversely proportional to message size, perhaps even exponentially.

        -After establishing a SAM session with STYLE=DATAGRAM, the client can -send datagrams through SAM's UDP port (7655). +After establishing a SAM session with STYLE=DATAGRAM or STYLE=RAW, the client can +send repliable or raw datagrams through SAM's UDP port (7655).

        The first line of a datagram sent through this port must be in the @@ -730,6 +729,15 @@ This is all on one line (space separated), shown on multiple lines for clarity: $destination [FROM_PORT=nnn] # SAM 3.2 or higher only, default 0 [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 + [PROTOCOL=nnn] # SAM 3.2 or higher only, only for RAW sessions, default 18 + [SEND_TAGS=nnn] # SAM 3.3 or higher only, number of session tags to send + # Default is router-dependent (40 for Java router) + [TAG_THRESHOLD=nnn] # SAM 3.3 or higher only, low session tag threshold + # Default is router-dependent (30 for Java router) + [EXPIRES=nnn] # SAM 3.3 or higher only, expiration from now in seconds + # Default is router-dependent (60 for Java router) + [SEND_LEASESET={true,false}] # SAM 3.3 or higher only, whether to send our leaseset + # Default is true \n @@ -741,6 +749,12 @@ This is all on one line (space separated), shown on multiple lines for clarity: The target is $destination, which is the base 64 of the Destination, which is 516 or more base 64 characters (387 or more bytes in binary), depending on signature type. +

      • + All options are per-datagram settings that override the defaults specified in the SESSION CREATE. +
      • + Version 3.3 options SEND_TAGS, TAG_THRESHOLD, EXPIRES, and SEND_LEASESET + will be passed to I2CP if supported. See the I2CP specification for details. + Support by the SAM server is optional, it will ignore these options if unsupported.
      • this line is '\n' terminated.
      @@ -750,7 +764,7 @@ The first line will be discarded by SAM before sending the remaining data of the message to the specified destination.

      -For an alternate method of sending repliable datagrams, see DATAGRAM SEND. +For an alternate method of sending repliable and raw datagrams, see DATAGRAM SEND and RAW SEND.

      SAM Repliable Datagrams : Receiving a Datagram

      @@ -800,6 +814,14 @@ CREATE command with PORT and HOST options: [FROM_PORT=nnn] # SAM 3.2 or higher only, default 0 [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 + [SEND_TAGS=nnn] # SAM 3.3 or higher only, number of session tags to send + # Default is router-dependent (40 for Java router) + [TAG_THRESHOLD=nnn] # SAM 3.3 or higher only, low session tag threshold + # Default is router-dependent (30 for Java router) + [EXPIRES=nnn] # SAM 3.3 or higher only, expiration from now in seconds + # Default is router-dependent (60 for Java router) + [SEND_LEASESET={true,false}] # SAM 3.3 or higher only, whether to send our leaseset + # Default is true [option=value]* # I2CP options @@ -869,7 +891,7 @@ depending on signature type.

      -

      SAM Anonymous Datagrams

      +

      SAM Anonymous (Raw) Datagrams

      Squeezing the most out of I2P's bandwidth, SAM allows clients to send and receive anonymous datagrams, leaving authentication and reply @@ -883,7 +905,7 @@ size is approximately 11 KB.

      After establishing a SAM session with STYLE=RAW, the client can send anonymous datagrams through the SAM bridge exactly the same way -he sends non anonymous datagrams. +as sending repliable datagrams.

      Both ways of receiving datagrams are also available for anonymous From 8d4c83548bd2df17fa7fef594b8af5ccea770225 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 7 Feb 2016 20:54:16 +0000 Subject: [PATCH 104/114] Use I2CP option names, not SAM option names, for setting tag options in SESSION CREATE/ADD --- i2p2www/pages/site/docs/api/samv3.html | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 6aac5398..f37aacc4 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -330,7 +330,6 @@ received through other forms are answered with an error message) : [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 [HEADER={true,false}] # SAM 3.2 or higher only, for STYLE=RAW only, default false - [v3.3 datagram and raw options] # see below [option=value]* # I2CP and streaming options @@ -731,12 +730,16 @@ This is all on one line (space separated), shown on multiple lines for clarity: [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, only for RAW sessions, default 18 [SEND_TAGS=nnn] # SAM 3.3 or higher only, number of session tags to send + # Overrides crypto.tagsToSend I2CP session option # Default is router-dependent (40 for Java router) [TAG_THRESHOLD=nnn] # SAM 3.3 or higher only, low session tag threshold + # Overrides crypto.lowTagThreshold I2CP session option # Default is router-dependent (30 for Java router) [EXPIRES=nnn] # SAM 3.3 or higher only, expiration from now in seconds + # Overrides clientMessageTimeout I2CP session option (which is in ms) # Default is router-dependent (60 for Java router) [SEND_LEASESET={true,false}] # SAM 3.3 or higher only, whether to send our leaseset + # Overrides shouldBundleReplyInfo I2CP session option # Default is true \n @@ -814,14 +817,6 @@ CREATE command with PORT and HOST options: [FROM_PORT=nnn] # SAM 3.2 or higher only, default 0 [TO_PORT=nnn] # SAM 3.2 or higher only, default 0 [PROTOCOL=nnn] # SAM 3.2 or higher only, for STYLE=RAW only, default 18 - [SEND_TAGS=nnn] # SAM 3.3 or higher only, number of session tags to send - # Default is router-dependent (40 for Java router) - [TAG_THRESHOLD=nnn] # SAM 3.3 or higher only, low session tag threshold - # Default is router-dependent (30 for Java router) - [EXPIRES=nnn] # SAM 3.3 or higher only, expiration from now in seconds - # Default is router-dependent (60 for Java router) - [SEND_LEASESET={true,false}] # SAM 3.3 or higher only, whether to send our leaseset - # Default is true [option=value]* # I2CP options From f091c500d36a7b55c74f1cc8d2936491c8684aef Mon Sep 17 00:00:00 2001 From: zzz Date: Wed, 10 Feb 2016 15:01:13 +0000 Subject: [PATCH 105/114] samv3 tweaks and intrapage links --- i2p2www/pages/site/docs/api/samv3.html | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index f37aacc4..522bb6bd 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -74,9 +74,9 @@ Version 3.2 was introduced in I2P release 0.9.24.

      SSL and Authentication

        -
      • USER/PASSWORD in the HELLO parameters for authorization. See below. -
      • Optional authorization configuration with the AUTH command. See below. -
      • Optional SSL/TLS support on the control socket +
      • USER/PASSWORD in the HELLO parameters for authorization. See below. +
      • Optional authorization configuration with the AUTH command. See below. +
      • Optional SSL/TLS support on the control socket. See below.
      • STREAM FORWARD option SSL=true
      @@ -87,7 +87,7 @@ Version 3.2 was introduced in I2P release 0.9.24.

      Command Line Parsing and Keepalive

        -
      • Optional commands QUIT, STOP and EXIT to close the session and socket. See below. +
      • Optional commands QUIT, STOP and EXIT to close the session and socket. See below.
      • Command parsing will properly handle UTF-8
      • Command parsing reliably handles whitespace inside quotes
      • A backslash '\' may escape quotes on the command line @@ -99,22 +99,23 @@ Version 3.2 was introduced in I2P release 0.9.24. -

        Version 3.3 Proposal

        +

        Version 3.3 Changes

        -Version 3.3 is not yet implemented, and the changes listed below are preliminary. +The version 3.3 changes listed below are preliminary. Scheduled for I2P release 0.9.25.

        • The same session may be used for streams, datagrams, and raw simultaneously. Incoming packets and streams will be routed based on I2P protocol and to-port. See the MASTER section below.
        • DATAGRAM SEND and RAW SEND now support options SEND_TAGS, TAG_THRESHOLD, EXPIRES, and SEND_LEASESET. + See the datagram sending section below.

        Version 3 Protocol

        -

        Simple Anonymous Messaging (SAM version 3.0) Specification Overview

        +

        Simple Anonymous Messaging (SAM) Version 3.3 Specification Overview

        The client application talks to the SAM bridge, which deals with all of the I2P functionality (using the streaming @@ -239,14 +240,14 @@ If some error occurred, such as a bad request format, it replies with:

        -

        SSL

        +

        SSL

        The server's control socket may optionally offer SSL/TLS support, as configured on the server and client. Implementations may offer other transport layers as well; this is outside the scope of the protocol definition.

        -

        Authorization

        +

        Authorization

        For authorization, client adds USER="xxx" PASSWORD="yyy" to the HELLO parameters. Double quotes for user and password are recommended but not required. @@ -723,7 +724,7 @@ following format. This is all on one line (space separated), shown on multiple lines for clarity: 

        -    3.0                                  # As of SAM 3.2, any 3.x is allowed
+    3.0                                  # As of SAM 3.2, any "3.x" is allowed. Prior to that, "3.0" is required.
     $nickname
     $destination
     [FROM_PORT=nnn]                      # SAM 3.2 or higher only, default 0
@@ -1215,7 +1216,7 @@ If a timeout occurs waiting for a PONG from the bridge, the client may simply di
 
        
 
 
-
        QUIT/STOP/EXIT (SAM 3.2 or higher, optional features)
        
+
        QUIT/STOP/EXIT (SAM 3.2 or higher, optional features)
        
 
        
 Commands QUIT, STOP and EXIT will close the session and socket.
 Implementation is optional, for ease in testing via telnet.
@@ -1235,7 +1236,7 @@ implementation-specific and outside the scope of this specification.
 
 
 
-
        Authorization Configuration (SAM 3.2 or higher, optional feature)
        
+
        Authorization Configuration (SAM 3.2 or higher, optional feature)
        
 
        
 Authorization configuration using the AUTH command.
 A SAM server may implement these commands to facilite persistent storage of credentials.

From 0d4d52a6efde4d2df87ffadbc5612e145fd1e3cb Mon Sep 17 00:00:00 2001
From: zzz 
Date: Sat, 13 Feb 2016 13:33:59 +0000
Subject: [PATCH 106/114] Clarify router family docs Add some coding style
 items

---
 .../pages/site/docs/how/network-database.html |  6 ++---
 .../get-involved/guides/dev-guidelines.html   | 24 +++++++++++++++++--
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html
index 1df1113c..99c3147b 100644
--- a/i2p2www/pages/site/docs/how/network-database.html
+++ b/i2p2www/pages/site/docs/how/network-database.html
@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}The Network Database{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %}
 {% block accuratefor %}0.9.24{% endblock %}
 {% block content %}
 
        {% trans %}Overview{% endtrans %}
        
@@ -118,8 +118,6 @@ statistics to improve anonymity, and we plan to remove more in future releases.
 
 
        {% trans %}Family Options{% endtrans %}
        
 
-
        Note: Preliminary, subject to change.
        
-
 
        {% trans -%}
 As of release 0.9.24, routers may declare that they are part of a "family", operated by the same entity.
 Multiple routers in the same family will not be used in a single tunnel.
@@ -134,7 +132,7 @@ The family options are:
 ({% trans %}The family name{% endtrans %})
      • family.key -The type code of the family's +The signature type code of the family's Signing Public Key (in ASCII digits) concatenated with ':' diff --git a/i2p2www/pages/site/get-involved/guides/dev-guidelines.html b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html index 20cef19d..67314026 100644 --- a/i2p2www/pages/site/get-involved/guides/dev-guidelines.html +++ b/i2p2www/pages/site/get-involved/guides/dev-guidelines.html @@ -1,6 +1,6 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Developer Guidelines and Coding Style') }}{% endblock %} -{% block lastupdated %}{% trans %}January 2016{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} {% block content %}

        {% trans newdevs=site_url('get-involved/guides/new-developers') -%} Read the new developers guide first. @@ -170,14 +170,34 @@ Don't use URL. Use URI. Don't catch Exception. Catch RuntimeException and checked exceptions individually. {%- endtrans %}

      • {% trans -%} -Don't use String.getBytes(). Use DataHelper.getUTF8() or DataHelper.getASCII(). +Don't use String.getBytes() without a UTF-8 charset argument. You may also use DataHelper.getUTF8() or DataHelper.getASCII(). +{%- endtrans %}
        • +
      • {% trans -%} +Always specify a UTF-8 charset when reading or writing files. The DataHelper utilities may be helpful. +{%- endtrans %}
        • +
      • {% trans -%} +Always specify a locale (for example Locale.US) when using String.toLowerCase() or String.toUpperCase(). +Do not use String.equalsIgnoreCase(), as a locale cannot be specified. {%- endtrans %}
      • {% trans -%} Don't use String.split(). Use DataHelper.split(). {%- endtrans %}
      • {% trans -%} +Ensure that InputStreams and OutputStreams are closed in finally blocks. +{%- endtrans %}
        • +
      • {% trans -%} Use {} for all for and while blocks, even if only one line. If you use {} for either the if, else, or if-else block, use it for all blocks. +Put "} else {" on a single line. +{%- endtrans %}
        • +
      • {% trans -%} +Specify fields as final wherever possible. +{%- endtrans %}
        • +
      • {% trans -%} +Don't store I2PAppContext, RouterContext, Log, or any other references to router or context items in static fields. +{%- endtrans %}
        • +
      • {% trans -%} +Don't start threads in constructors. Use I2PAppThread instead of Thread. {%- endtrans %}
      From 5745430abda12499bac3d8ed5d4bedf27385ed80 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 13 Feb 2016 16:37:05 +0000 Subject: [PATCH 107/114] new i2ptunnel HTTP server options --- i2p2www/pages/site/docs/spec/configuration.html | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/configuration.html b/i2p2www/pages/site/docs/spec/configuration.html index 902c8da6..aaf10d8a 100644 --- a/i2p2www/pages/site/docs/spec/configuration.html +++ b/i2p2www/pages/site/docs/spec/configuration.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Configuration File Specification{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}November 2015{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.24{% endblock %} +{% block lastupdated %}{% trans %}February 2016{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.25{% endblock %} {% block content %}

      {% trans %}Overview{% endtrans %}

      {% trans -%} @@ -337,9 +337,20 @@ tunnel.N.option.proxy.auth.USER.md5= # HTTP Servers only. Whether to reject incoming connections apparently via an inproxy. Default false. tunnel.N.option.rejectInproxy=true|false +# HTTP Servers only. Whether to reject incoming connections containing a referer header. Default false. Since 0.9.25. +tunnel.N.option.rejectReferer=true|false + +# HTTP Servers only. Whether to reject incoming connections containing specific user-agent headers. Default false. Since 0.9.25. +# See tunnel.N.option.userAgentRejectList +tunnel.N.option.rejectUserAgents=true|false + # Servers only. Overrides targetHost and targetPort for incoming port NNNN. tunnel.N.option.targetForPort.NNNN=hostnameOrIP:nnnn +# HTTP Servers only. Comma-separated list of strings to match in the user-agent header. Since 0.9.25. +# Example: "Mozilla,Opera". Case-sensitive. See tunnel.N.option.rejectuserAgents +tunnel.N.option.rejectUserAgents=true|false + # Default false. For servers, use SSL for connections to local server. # For clients, SSL is required for connections from local clients. tunnel.N.option.useSSL=false From a99153e7585f71bd9042d8b100d6bec54cd21dea Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 13 Feb 2016 16:43:31 +0000 Subject: [PATCH 108/114] fix --- i2p2www/pages/site/docs/spec/configuration.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/docs/spec/configuration.html b/i2p2www/pages/site/docs/spec/configuration.html index aaf10d8a..018ea23b 100644 --- a/i2p2www/pages/site/docs/spec/configuration.html +++ b/i2p2www/pages/site/docs/spec/configuration.html @@ -349,7 +349,7 @@ tunnel.N.option.targetForPort.NNNN=hostnameOrIP:nnnn # HTTP Servers only. Comma-separated list of strings to match in the user-agent header. Since 0.9.25. # Example: "Mozilla,Opera". Case-sensitive. See tunnel.N.option.rejectuserAgents -tunnel.N.option.rejectUserAgents=true|false +tunnel.N.option.userAgentRejectList=string1[,string2]* # Default false. For servers, use SSL for connections to local server. # For clients, SSL is required for connections from local clients. From 458477d122b0b13951ea2d65b1397602918be8db Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 21 Feb 2016 16:15:14 +0000 Subject: [PATCH 109/114] reseed guide minor updates --- .../pages/site/get-involved/guides/reseed.html | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/site/get-involved/guides/reseed.html b/i2p2www/pages/site/get-involved/guides/reseed.html index b2320304..0fee7bd5 100644 --- a/i2p2www/pages/site/get-involved/guides/reseed.html +++ b/i2p2www/pages/site/get-involved/guides/reseed.html @@ -35,7 +35,7 @@ The scripts are designed to deliver different router info bundles to different r The scripts are designed to deliver the same bundle to the same repeated requestor to prevent scraping {%- endtrans %}

    21. {% trans -%} -The reseed servers are under periodic attacks and DDoS attempts, and from buggy botnet i2pd routers. +The reseed servers are under periodic attacks and DDoS attempts, and from other buggy I2P implementations and botnets. This necessitates that you run fail2ban or an equivalent solution. {%- endtrans %}
      22. @@ -60,6 +60,20 @@ While we do not yet have a formal privacy policy, you must ensure the privacy of by not publicizing logs or IPs found in those logs, except as necessary to discuss administration issues with the I2P reseed team. {%- endtrans %}

      +

      {% trans %}Financial Support{% endtrans %}

      + +

      {% trans -%} +Modest financial support may be available to those running reseed servers. +This support would be in partial reimbursement for your server costs. +Support will not be paid in advance and will probably not cover all your expenses. +Support is only available to those who have been running reseed servers in good standing for several months, and is based on actual need. +{%- endtrans %}

      + +

      {% trans -%} +If you would like to discuss support, please contact echelon and CC: backup. +{%- endtrans %}

      + +

      {% trans %}Getting Started{% endtrans %}

      {% trans -%} From c8a0cc43b7f341fce3fe34943ace8924b5f93c7e Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 1 Mar 2016 13:51:04 +0000 Subject: [PATCH 110/114] add paper --- i2p2www/pages/papers/anonbib.bib | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/i2p2www/pages/papers/anonbib.bib b/i2p2www/pages/papers/anonbib.bib index 31f02732..f8bb13d9 100644 --- a/i2p2www/pages/papers/anonbib.bib +++ b/i2p2www/pages/papers/anonbib.bib @@ -29,6 +29,18 @@ @string{lncs = "Lecture Notes in Computer Science"} +@article{liu2014, + title = {Empirical Measurement and Analysis of I2P Routers}, + author = {Peipeng Liu et al}, + journal = {Journal of Networks}, + year = {2014}, + month = Sep, + volume = {9}, + issue = {9}, + pages = {2269--2278}, + www_section = traffic, +} + @inproceedings{conrad2014, title = {A Survey on Tor and I2P}, author = {Bernd Conrad and Fatemeh Shirazi}, From 4f720fbc5059034d453dc1c12d929c4597326d42 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 5 Mar 2016 14:12:05 +0000 Subject: [PATCH 111/114] meetings 242-244 --- i2p2www/meetings/logs/242.log | 407 ++++++++++++++++++++++++++++++++++ i2p2www/meetings/logs/242.rst | 9 + i2p2www/meetings/logs/243.log | 230 +++++++++++++++++++ i2p2www/meetings/logs/243.rst | 9 + i2p2www/meetings/logs/244.log | 320 ++++++++++++++++++++++++++ i2p2www/meetings/logs/244.rst | 9 + 6 files changed, 984 insertions(+) create mode 100644 i2p2www/meetings/logs/242.log create mode 100644 i2p2www/meetings/logs/242.rst create mode 100644 i2p2www/meetings/logs/243.log create mode 100644 i2p2www/meetings/logs/243.rst create mode 100644 i2p2www/meetings/logs/244.log create mode 100644 i2p2www/meetings/logs/244.rst diff --git a/i2p2www/meetings/logs/242.log b/i2p2www/meetings/logs/242.log new file mode 100644 index 00000000..b997466f --- /dev/null +++ b/i2p2www/meetings/logs/242.log @@ -0,0 +1,407 @@ +20:00:00 Agenda http://zzz.i2p/topics/2014 +20:00:00 0) Hi +20:00:00 1) Review of assigned tasks from Dec. 30 meeting - http://zzz.i2p/topics/2016 (zzz) +20:00:00 2) Other CCC followup - http://zzz.i2p/topics/2019 (zzz) +20:00:00 3) Project meeting plan for 2016 (zzz, Sadie) +20:00:00 4) GMP 6 readiness for merging - http://zzz.i2p/topics/1960 (tuna) +20:00:00 5) http://secure.tinhat.i2p console home page request - http://zzz.i2p/topics/236?page=3#p10884 (david) +20:00:00 6) Proposal for Code of Conduct - http://zzz.i2p/topics/2015 (Sadie) +20:00:02 There is a link to it in the ccc blog post +20:00:05 0) Hi +20:00:09 hi +20:00:19 hi +20:00:21 hi +20:00:25 Hello +20:00:32 hi +20:00:33 hi +20:00:37 1) Review of assigned tasks from Dec. 30 meeting - http://zzz.i2p/topics/2016 (zzz) +20:00:44 Hey +20:00:48 ok, let's quickly go through the open items only +20:00:49 Hi +20:00:50 hi +20:00:55 Hi +20:01:03 gravy to post one on encrypted leasesets by Jan. 27 +20:01:11 lazygravy, what's the status? +20:01:34 hi +20:01:37 zzz: very late on that. But it is "started". I still plan on writing it +20:01:38 hi +20:01:44 hi +20:01:50 Might change the topic , but my point stands +20:01:51 lazygravy, what's the new target date? +20:02:27 oops +20:02:28 hi +20:02:37 zzz: president's day weekend? +20:02:52 got a date for that? +20:03:10 15 Feb +20:03:14 ok thanks +20:03:17 Sadie to work with J to get his blog post up +20:03:32 sadie_i21,status? +20:03:42 mid feb +20:03:55 vodka anyone? +20:04:02 Sadie to contact backup to discuss reseed campaign +20:04:05 sadie_i21,status? +20:04:12 hi +20:04:27 not yet +20:04:39 new due date please? +20:06:09 ok, we'll move on, sadie please let me know +20:06:10 mid feb for this too +20:06:10 hi +20:06:13 Strengthinging the network - home page and additional pages +20:06:13 ** str4d, gravy, cacapo: Add use cases, what are we best at, more "passion" and "fat", add / highlight Bote, by end of January +20:06:17 ok thx sadie +20:06:31 str4d, lazygravy, cacapo, status? +20:07:08 we're working on it but need feedback from community i think +20:07:16 hi +20:07:16 cacapo++ +20:07:22 hallo +20:07:40 new due date please? +20:08:42 also I don't think we're clear on the end purpose. Is it for a blog post? +20:08:50 cacapo: if you need me to read through it again, please ping me +20:08:50 march 1st +20:09:07 please also try to target researchers, not just end-users +20:09:07 The scope AFAICT is to alter the homepage and the "supported applications" page, no? +20:09:18 iirc the intention was to enhance the home page and possibly add additional pages. Not a blog post +20:09:33 sadie_i21, could you elaborate please? +20:09:34 Ok, nvm in that case +20:09:38 Right +20:09:47 so it's the supo +20:09:59 supported applications page then? +20:10:26 iirc the priority was the home page. If it spilled over to other pages (new or not), that's ok too +20:10:55 also: do we talk about torrents for PR? +20:11:06 unless sadie has something to add, let's move on +20:11:22 we can discuss torrents or not outside the meeting +20:11:37 nope +20:11:38 sadie_i21, the Simply Secure design thoughts are probably relevant here too. +20:11:39 If they have any immediate thoughts regarding the homepage, that will affect how the use cases stuff is written up and presented/ +20:12:00 comraden to edit / polish / enhance / post the "i2p story" by end of February +20:12:06 sorry zzz, on a call... +20:12:09 comraden1, you on track for that? +20:12:13 cacapo, I say yes, highlighting benefits of torrents (e.g. downloading new versions of Tails!) +20:12:17 sadie_i21: do you have the press@geti2p.net spam firehose forwarding at your email yet? +20:12:42 psi, please take that offline with sadie +20:12:45 no, not yet +20:12:50 kk +20:13:09 ok, we will assume comraden1 is on track +20:13:17 broader roadmap and priority setting processes are TBD, but should come out of the evolving project meetings +20:13:26 zzz: haven't read the post you put up yet, as I mentioned to you earlier I had an emergency I had to attend to +20:13:50 that item is mine and sadie's, let's defer that to item 3) +20:13:52 I will be looking at the history sometime this week and will reach back out with corrections to you & lance +20:14:05 comraden1, are you on track for end february? +20:14:26 zzz, the draft is certainly interesting :) +20:14:31 cacapo, regarding how it appears on the website, I think it would work well having it interspersed with year headers (breaking it into "chapters" as it were). Also would mean we could navigate through it by year. +20:14:34 zzz: so far, yes :) +20:14:45 sadie to review, make recommendations or possibly start managing tickets (by when?) +20:14:55 sadie_i21, status? due date? +20:15:55 ok we'll assume she's still on a call, please get back to us +20:16:05 4) Android - +20:16:05 kinda like 1) in that it's code and tied to the java router, but like 3) in that it's ad hoc or a one-man show by str4d, and he's behind. +20:16:13 DM from @YrB1rd: "There. Are. So. Many." +20:16:24 (a few days ago, but you get the idea ;P) +20:16:57 this wasn't really a todo item, but str4d you have any proposal on how to manage android development, or can we give you and/or sadie a more specific assignment on this? +20:17:09 Yah, basically everything that had me as a primary dependency was completely shot for the last 4-5 months. +20:17:36 can you give us a target for a 0.9.24 release, and perhaps another target to come up with a plan on how to manage android better? +20:17:39 Because I've been writing my PhD thesis. +20:18:08 Targeting submission at the end of this week, so that will be out of the way, but I will also be taking on paid work after then. +20:18:23 feb. 5, great +20:18:33 0.9.24: going to aim for this weekend. +20:18:38 zzz - can we circle back to ticket question - I am only half here rn +20:18:56 circle back now or circle back later? +20:19:16 later +20:19:22 Beyond that: what I need is a better roadmap, so I can do slow targeted development instead of "oh, another I2P release is coming up, I need to clear some Android work so I can do a release". +20:19:23 ok, end weekend is feb. 7 for 0.9.24 +20:19:48 ok str4d, due date when you'll have a roadmap? +20:20:42 anything else on item 1) ? +20:20:50 I have a bunch of to-do items locally, in-repo and in-Trac. What I need is more eyes on planning. +20:21:30 so you can't even give us a date, that's a bad sign. Can you throw up a draft roadmap out of your todo list? +20:21:34 zzz, I'd say March 6, I can draft something up earlier but I expect we will end up doing roadmapping on that along with everything else while I'm over. +20:21:40 ok, march 6 +20:21:44 last call for 1) +20:21:57 2) Other CCC followup - http://zzz.i2p/topics/2019 (zzz) +20:22:13 I put 2) in here just as a placeholder in case there were other important followups +20:22:18 I'll target Feb 26 for collating all the todo items and possibly drafting a roadmap. +20:22:26 I've been corresponding with Phillip Winter about Sybil +20:22:39 anybody else have interesting followups to report? +20:23:02 nothing from my side +20:23:25 ok, I encourage you all to send some emails out or do the research you wanted to do, it's not too late +20:23:26 Were we going to cover VRP this meeting? +20:23:26 finances will be updated this weekend IMHO +20:23:44 VRP is not on the agenda, if we have time we can add it as 7) +20:23:49 last call for 2) +20:23:58 Dear zzz ! I am very grateful to you for the creation of this network because I have met wonderful people here and find rare content, for which our country is suspended for the genitals an apple tree. Long old are you! +20:23:58 I'm sorry, who checked the safety 0.9.24 +20:24:11 I have a few people I need to follow up with from RWC +20:24:13 (shoehorning that into 2)) +20:24:31 3) Project meeting plan for 2016 (zzz, Sadie) +20:24:44 While shoehorning, I need to talk to you about i2spy str4d. But that is for later/offline +20:24:57 ok, just a brief item. We decided at the Dec. 30 meeting to get more serious about project management +20:25:03 to hold monthly meetings +20:25:14 and to have somebody act as a project manager +20:25:37 so this is the first monthly meeting, and they will be the first tuesday of every month at 8 PM UTC +20:25:56 except for next month, which will be on Thurs. Mar. 7 +20:26:26 the goal is for me to run these meetings for a little while, but after a few, to turn them over to Sadie and have her be our project manager +20:26:34 sound good? any comments? +20:26:39 Seems reasonable. Hopefully it will keep us all accountable. +20:26:59 La +20:27:03 lazygravy++ +20:27:04 Will sadie_i21 be on IRC more often? +20:27:15 C0B4, good point! +20:27:15 anonimal++ +20:27:22 okee dokee +20:27:33 Sounds good to me +20:27:42 that's a good point, we've repeatedly encouraged sadie_i21 to be here more often, I know she was working on a 2nd computer to make it easier +20:27:48 sadie_i21, I still have that bouncer account - sadie - if you want it +20:28:04 i think it will be difficult to manage the project if you aren't here very often +20:28:28 Hi sadie_i21, we've never officially said hi. +20:28:28 I have PM-related questions, but I think they can wait? +20:28:30 That would at least enable you to not miss PMs etc. +20:28:39 sadie_i21, any progress on getting a setup so you can be here and see scrollback? +20:28:52 hi! I am trying to be here more!! +20:28:57 s/PM-related/Project Management-related/ +20:29:06 str4d: talk to me on how to set that up for sadie_i21 offline? Twitter or here is fine +20:29:14 yes, zzz - all done ansset up +20:29:43 ok, we have the general migration plan from me to sadie, lets see how it goes over the next few months +20:29:47 sorry to interrupt, as sadie will get manager(in), system she needs to be organized +20:30:01 hardware she need, sorry +20:30:20 echelon huh? +20:30:41 comraden1, k +20:31:00 anything else on 3) ? +20:31:05 eche|on: I setup a computer for her so that might not be necessary, but that's her call of course if she wants a new piece of equipment +20:31:14 zzz: sorry, we talked about a pc system she needs, and she shopuld get in contact with me +20:31:23 ok +20:31:29 4) GMP 6 readiness for merging - http://zzz.i2p/topics/1960 (tuna) +20:31:35 hottuna, what's the latest? +20:31:38 if thats the point, IMHO it is fine, but the meeting round here can vote yes! +20:31:56 jcpuid for windows x86isn't working +20:32:05 I have two options left to test, then I'm 100% out of ideas +20:32:40 ok. kytv did it successfully 5 years ago, if you hit the wall maybe he can help +20:32:48 jcpuid is c code? +20:32:58 ucpuid for osx has not been compiled or tested +20:32:58 jcpuid* +20:33:13 c+asm+java-bindings +20:33:13 I'd like to have major stuff like this propped for 0.9.25 by mid-Feb, so we have about two weeks to make it happen +20:33:24 hottuna: I can help with that. +20:33:31 There's also another alternative we could look int +20:33:41 zzz: I can't make any promises. I'm hitting a bit of a wall here +20:33:47 anonimal: help with osx builds? +20:33:48 orignal raised the point a while back that our ElGamal implementation could be a lot more efficient. +20:33:52 or help with windows x86? +20:34:02 str4d: how? +20:34:04 (currently it just does the ElG math directly) +20:34:07 by having it be all c? +20:34:12 let's not get sidetracked on ElG +20:34:17 in the meeting +20:34:25 hottuna, using e.g. Montgomery ladder or something +20:34:30 Still to be looked into +20:34:35 ok +20:34:41 C0B4 for example, nobody. All people just believe a word about the safety and anonymity of the network. +20:34:53 ok so the summary is that hottuna needs help and the clock is ticking or we will miss .25. everybody please help if he asks +20:35:00 hottuna: Yes. I'm always strapped with time these days + Kovri, so I'll do what I can. +20:35:08 anything else on 4) ? +20:35:14 hottuna: Latest link is in the forum post? +20:35:34 I'm useless for testing unfortunately +20:35:36 links for what? +20:35:40 for jcpuid? +20:35:47 str4d, 100% +20:36:18 5) http://secure.tinhat.i2p console home page request - http://zzz.i2p/topics/236?page=3#p10884 +20:36:27 The_Tin_Hat, please tell us about your site +20:37:10 Justification - for the weak! +20:37:16 The site provides a number of practical tutorials on privacy and security, aimed at being digestible by intermediate users, including a number of tutorials on i2p and tor +20:38:03 I think its relevant for people who are just getting into I2P and/or internet security and privacy +20:38:03 I know you've been around at thethinhat.i2p for a while, what's with the relatively new secure.thetinhat.com? how long has each been around? +20:38:08 I know thetinhat from long +20:38:18 I translated some of those tutorials +20:38:23 zzz, IIUC secure.thetinhat.i2p is an EdDSA key +20:38:44 thetinhat.i2p still exists, but the subdomain was added when i switched servers and upgraded the key, along with longer tunnels +20:38:53 I'm sorry, but I wait long for an answer to the question, or you're not respond to mere mortals>>> I'm sorry, who checked the safety 0.9.24 +20:38:53 anybody have any questions or comments about this request? +20:38:57 So 5a) we need to extend the subscriptions feeds to enable key upgrades +20:39:16 C0B4, we're in the middle of a meeting, sorry +20:39:43 str4d, we'll talk about 5a) in the roadmap meetings next month +20:39:52 b +20:40:15 I am +1 on adding. +20:40:47 +1, add it +20:40:52 hottuna: Yes, jcpuid. +20:40:56 ok re: secure.thetinhat.i2p console home page request, if there are no other questions or comments, please vote +1 or -1 +20:40:59 +1 +20:41:13 Hi, gays! +20:41:23 +1 +20:41:23 +1 +20:41:51 +1 for adding +20:41:53 hottuna: Or are we working directly from mtn now? (I haven't seen anything since I last tested) +20:42:24 anonimal, we've moved off that topic, please discuss elsewhere, thanks +20:42:32 ok last call for 5) +20:42:37 +1 +20:43:06 hearing no objections, we'll approve the thinhat request, I'll check it in for .25 +20:43:27 6) Proposal for Code of Conduct - http://zzz.i2p/topics/2015 (Sadie) +20:43:27 6a) Proposal and reasoning (Sadie) +20:43:27 6b) Questions for Sadie +20:43:27 6c) Brief comments from those who have NOT already commented on zzz.i2p +20:43:27 6d) Brief Comments from those who HAVE already commented on zzz.i2p +20:43:27 6e) Volunteers to present specific proposal at next meeting +20:43:50 I'd like to limit this topic to about 20 minutes. We aren't going to make any final decision today +20:43:53 6a) Proposal and reasoning (Sadie) +20:44:01 sadie_i21, you're up +20:45:30 ok we lost sadie, let's move to 6b +20:45:36 er, 6c +20:45:40 zzz: Edward Snowden wrote that i2p not safe +20:45:44 6c) Brief comments from those who have NOT already commented on zzz.i2p +20:46:09 if you have not already added your thoughts to the zzz.i2p thread, please comment on this proposal now +20:46:13 6с, imho CoC is completely useless +20:46:32 a adult person must have it in thier head +20:47:02 rather than create policy, CoC and other HR's sh#t +20:47:29 zzz: I'm for a coc (had lazygravy post a link to the nsa's coc as an example). This is part of project maturity for development and to ensure that we can get more than just programmers involved with i2p +20:47:41 do jobs instead policies +20:47:53 I am on the point, as is should already be acked by us all, we can also write it down and fix the unwritten rules. No change at all. +20:48:02 zzz: I'm *for* a CoC. +20:48:04 * orignal believes you will get less programmers +20:48:04 anybody else who hasn't commented on the zzz.i2p thread wish to add their thoughts? +20:48:16 please be brief with your comments +20:49:05 being brief. We are not going to introduce any CoC for i2pd. +20:49:18 ok. let's circle back to 6a). sadie_i21 please fill us in on your proposal, what you had in mind, and why +20:49:19 period +20:50:15 anonimal: I have not seen more boring than you... +20:50:24 Probably a CoC is not very important, but I'm not against. +20:50:24 It's more or less a formality +20:50:40 One comment: +20:50:43 CoC's not only protect victims but also protect offenders from making stupid decisions that have longterm consequences such as career or personal. +20:50:43 I can comment more in the thread. EOT. +20:50:56 ok, 6d) let's throw it open for other comments, even if you have already commented in the zzz.i2p thread +20:51:18 anybody feel that they weren't clear in the thread or wish to add more thoughts? +20:52:03 I was looking for feedback on the idea of having comminity standards +20:52:04 anonimal: Yeah, but let's consider the fact that most offenders will be anonymous. +20:53:00 What is it going to be used for? Sending to reporters? Expell project members? +20:53:02 to zzz's point, in line with the maturity of the project +20:53:08 I feel similar to EinMByte. It is either useless, or good. Not some end of the world event as some have made it seem +20:53:08 EinMByte: So far, I've seen 50/50 on that (one anonymous, one not anonymous) but I see your point. +20:53:08 Useless meaning a net zero, not negative +20:53:08 anonimal, it is a priori a criminal. Why defend him& +20:53:09 sadie, you simply wanted general feedback on the idea of any standard or CoC at all? You haven't (yet) offered a specific example to consider +20:53:26 EinMByte: ideally we can start with ways to address this. I will link this again https://github.com/NationalSecurityAgency/SIMP/blob/master/Community_Code_of_Conduct.md as I think the guideline violations part is something we can enforce +20:53:31 A CoC is useless and a shot in the foot IMO +20:53:37 anonimal: Well if you plan on offending people, it's probably wise to remain anonymous ;). +20:53:39 PR wise +20:53:39 zzz: I wrote that the Russian written on the client C++. It's true? +20:53:57 Yankee, we're in the middle of a meeting, sorry +20:54:00 also, would having one help us if we were to apply for grants, etc +20:54:21 sadie_i21: That might be true, good point. +20:54:33 orly? grants are important +20:54:34 also i have been accused of spreading FUD +20:54:38 Debian and thousands of other projects use one and their PR is fine. How do you contest this? +20:54:39 thanks to everyone who took the time to share ideas on the forum btw about this +20:54:50 Yankee: Pashol na xyi :) +20:54:53 * orignal agress with zab__ +20:55:22 * orignal is for CoC after last anonimal's phrse +20:55:30 lazygravy: saddie just proposed community standards which you said never would happen +20:55:33 zab__: this is what sadie_i21is referring to, new stance by the NSF in America https://www.nsf.gov/news/news_summ.jsp?cntn_id=137466 +20:55:41 sadie_i21: Thanks for bringing it to our attention. +20:55:59 sadie_i21, did you mean the community as a whole, or just the dev community? +20:56:00 psi: the FUD needs to stop. Its the dev community +20:56:01 ok, sadie_i21 would you like to come back at the next meeting with a specific proposal? or not proceed? what's the next step? +20:56:09 anonimal: what? +20:56:11 lazygravy: it's not fud... +20:56:24 guys, I'm sorry do you believe swearing is aloowed here? +20:56:32 not the community as a whole - no. +20:56:44 CoC. what you will do with 'bad people' technically? (sorry for my en) +20:56:44 sadie_i21, r u not a HR for a living? +20:57:06 psi: it is. But this is a offline discussion. +20:57:09 * zab__ smiles +20:57:25 Yankee: подожди, сейчас встреча +20:57:25 wrote letters to government or what? +20:57:34 an +20:57:45 a CoC is the wrong thing for i2p +20:57:52 do we have any volunteers to work on a specific proposal for next month, in light of the comments here and on the zzz.i2p thread? +20:57:52 anonimal, ты не хотел бы извиниться за мат? +20:58:07 zab__, один мудак позоволил себе вольность послать нах при женщинах +20:58:15 nda: in last line of work, exclude from our java main fork dev work for some time? +20:58:17 anonimal, вот да. Мы, вообще-то, не ругаемся, сдерживаемся. А ты? +20:58:21 guys, please stay on topic and in english, thanks +20:58:23 lets come up with a proposal for the next meeting +20:58:40 ok, anybody volunteer to work with sadie? +20:58:44 zzz, anonimal was firsr +20:58:53 zzz, sorry, but and you developer first +20:58:56 zzz: I can assist whoever with links to ideas, etc. I can't commit myself to doing all the work because of my life falling apart at the moment :) +20:58:58 he sais something very offensive for everybody +20:59:02 *your +20:59:04 eche|on oh thanks for your answer +20:59:10 I promise to read the CoC thoroughly and have an opinion +20:59:19 zzz sadie_i21: I would like to help. +20:59:35 I do not think we have agreed on a specific text +20:59:48 I need to spend a little more java i2p time than a VRP and rewriting/reorganzing docs. +20:59:49 (Which is super important, IMO. One could be worded horribly) +21:00:04 ok. In summary it appears that more "team members" (either checkin privs or on our team page) are in favor than opposed, while among non-team-members, more are opposed +21:00:21 lazygravy, yep. And I wouldn't think that specific text would even be agreed on at next meting +21:00:21 meeting* +21:00:25 I think both groups are important to consider, as non-team-members may become team members +21:00:39 we would ideally come up with more than one candidate coc +21:00:41 I think that we have a bunch of proposals, as well as several reasons for and against. +21:01:13 As I suspect I will be the final arbiter of any code or process, I'm not at all eager to adopt anything that doesn't have broad or near-unanimous consensus +21:01:21 A good starting point would be for some people to review the proposed options, looking at pros and cons +21:01:38 ok, sadie sounds like your name is on the assignment to bring something back next month +21:01:44 anything else on 6) ? +21:02:02 noted +21:02:10 Additional research around the positive and negative impressions of "CoC"s or similar would be useful (e.g. the grants issue above, or the negative impressions that appear to be main objections) +21:02:16 I can't make up my mind until I actually get to see a proposal, I think +21:02:17 But that would be more involved +21:02:34 and with CoC you will nothing to do with 'bad people' who not from your i2p-team? +21:02:44 last call for 6) +21:02:57 str4d++ +21:03:09 nda, the CoC or whatever would only be for the I2P dev team, yes +21:03:25 * lazygravy afks, irl came up +21:03:27 nda: why should we? it is for our i2p-dev-team +21:03:29 Basically, we need more data. +21:03:40 str4d ok thank you +21:03:44 (for now) +21:03:45 zab__: not a bad idea. It makes sense to look at what's available that we can copy from rather than roll our own +21:03:49 ok, I declare an end to 6), thanks everybody +21:03:59 7) VRP anonimal go +21:04:03 In essence, it would be an extension to the developer agreements we already have to sign. +21:04:40 Re: VRP: I'm awaiting respones from zzz and str4d and community. +21:04:57 Then I can re-write and wrap-up the ticket. +21:04:59 i thinked that this something like "Call Police this is bad man in I2P!" really sorry ) +21:05:01 And to add to str4d's point, it would also ensure a baseline for those who didn't sign a dev agreement (like myself) +21:05:08 anonimal, oh, have there been further updates? Sorry I missed them. +21:05:09 i don't have the ticket number in front of me. what do you need? I know str4d met with Kate recently. str4d what's the latest? +21:05:26 what is VRP` +21:05:26 ? +21:05:36 eche|on, Vulnerability Response Process +21:05:37 http://trac.i2p2.i2p/ticket/1119 +21:05:37 anonimal, you have that ticket? +21:05:39 ah, ok +21:05:52 a complicated topic +21:06:04 i don't think we've even decided to use H1 yet, have we? But clearly they've made a big splash recently +21:06:15 zzz, I haven't followed up with Katie yet regarding the OSS bug bounty program (thesis), but will do so this week. +21:06:38 I certainly got a good impression from her, as well as from their response on our ticket +21:06:38 would this be a good thing to decide on once and for all during our roadmap meetings next month? +21:06:40 I think that was the biggest hurdle: the H1 decision. +21:06:40 They commented in the ticket, made their case, +21:06:41 I've made my case, +21:06:43 kay made their case, +21:06:52 Katie also had good comments about the process we are going through +21:07:33 I'm not sure we'll be able to focus enough to make decisions before march. I'm a little overwhelmed though with the detail in the ticket. It may be too much. but maybe not. +21:08:02 str4d, how and when should we tackle this? +21:08:37 Katie liked the detail and lengths we were going to making sure we got this right, FWIW +21:08:52 fine, but I care what you think, not katie so much :) +21:09:05 zzz, if we did manage to get into the same bug bounty program Tor is on, I think that would probably decide it for us +21:09:09 how and when do we get to an answer +21:09:37 because I think we'd have a larger influx of researchers than if we just had a free page +21:09:47 Since this was postponed from December's meeting, I'm not exciting for another postponement +21:09:47 But I really am in no place to argue or make requests. +21:09:47 So, whatever works for everyone else. +21:09:47 s/exciting/excited/ +21:09:55 yeah but independent of H1, we need a process +21:10:04 Yep +21:10:24 so I propse we work on it during the roadmap meetings in march. OK? +21:10:31 I will review anonimal's latest changes next week. +21:10:41 ok, I'll do that too +21:10:49 anything else on 7) ? +21:10:54 By Feb 12 +21:11:02 anonimal, It was frustrating when you allowed yourself to swear around me. +21:11:18 Did my last 4 lines get through? +21:11:18 * comraden1 has to run afk +21:11:29 anything else for the meeting? +21:11:32 anonimal, I saw up to s/ +21:11:40 anonimal, I demand an apology. +21:11:42 * zzz warms up the *baffer +21:11:52 I'll review the meeting log, I think I missed a bunch of text. +21:11:57 8) anonimal's phrase +21:12:09 * zzz *bafffs* the meeting closed diff --git a/i2p2www/meetings/logs/242.rst b/i2p2www/meetings/logs/242.rst new file mode 100644 index 00000000..dad65f3f --- /dev/null +++ b/i2p2www/meetings/logs/242.rst @@ -0,0 +1,9 @@ +I2P dev meeting, February 2, 2016 @ 20:00 UTC +============================================= + +Quick recap +----------- + +* **Present:** + +i2p-devs, diff --git a/i2p2www/meetings/logs/243.log b/i2p2www/meetings/logs/243.log new file mode 100644 index 00000000..6bb07a17 --- /dev/null +++ b/i2p2www/meetings/logs/243.log @@ -0,0 +1,230 @@ +20:00:02 0) Hi +20:00:02 1) Review of old assigned tasks still open from Dec. 30 meeting http://zzz.i2p/topics/2014 +20:00:02 2) Review of new assigned tasks from Feb. 2 meeting http://zzz.i2p/topics/2014 +20:00:02 3) Prep and schedule for roadmap meetings http://zzz.i2p/topics/2021 +20:00:02 4) Code of Conduct proposal (Sadie) http://zzz.i2p/topics/2015?page=2 +20:00:12 0) Hi +20:00:15 hi +20:00:25 Hi +20:00:38 Hi +20:01:07 1) Review of old assigned tasks still open from Dec. 30 meeting http://zzz.i2p/topics/2014 +20:01:19 hi +20:01:37 gravy to post one on encrypted leasesets by Jan. 27, or different topic, by Feb. 15 +20:01:51 anybody know about gravy's status? +20:03:13 Nope. +20:03:47 busy irl +20:04:07 sadie_i2p, you have a new date from him? +20:04:24 waiting for new date from Gravy +20:04:33 ok, we'll roll it over to next meeting +20:04:42 Sadie to work with J to get his reseed blog post up, new date mid-Feb. +20:04:49 sadie_i2p, what's the latest on this? +20:05:42 J is busy also, working with Back up +20:06:07 sadie_i2p, is a blog post going to happen at this point or should we move on? +20:06:44 back up and I working on something else at this point - blog post will probably not happen +20:06:58 ok, I'll scratch it off the list +20:07:02 move on +20:07:17 Sadie to contact backup to discuss reseed campaign, new date mid-Feb. +20:07:32 sadie_i2p, what are you and backup cooking up? +20:07:34 Feb? +20:07:54 yes anonimal these are all past-due items +20:08:26 new content and graphics +20:08:51 for the website i presume +20:08:55 there will be delays on this due to schedules but back up is now working on content and I am working on graphics for the site +20:09:15 what about the "campaign" beyond the website itself? +20:09:30 what do you guys have planned? and when? +20:09:34 great +20:09:47 we will prepare a new page for the site and then begin directing people there via social media etc... +20:10:00 maybe use new stickers as incentive too +20:10:10 stickers! +20:10:17 ooh yeah, stickers to reseeders, great idea +20:10:19 Is this a "what is reseed" page, or a "how to run a reseed" guide? +20:10:49 this is a new how to run a reseed guide +20:11:36 sadie_i2p, can you please give us the next milestone for this? (date, what it is) +20:12:12 This would be a guide for "users" of or contributors to I2P then, rather than developers +20:12:26 So I'll think of a better place to put these guides +20:13:07 this has the potential to take a bit longer - I will say in two months time latest +20:13:10 except hmm... +20:13:21 The guide will be for users of and contributors +20:13:45 sadie_i2p, please give us an intermediate milestone for next month +20:13:59 can probably provide content up date in one month +20:14:02 Actually, I guess it does belong under "Get involved -> Guides" +20:14:11 ok great +20:14:16 moving on +20:14:26 str4d, gravy, cacapo: Add use cases, what are we best at, more "passion" and "fat", add / highlight Bote, by end of +20:14:39 January OPEN, new date March 1 +20:14:50 I saw that cacapo wrote up some nice use cases +20:15:06 Yah, based on dymaxion's examples +20:15:11 str4d, what's the status on pulling that into the website along with some passion and fat? +20:15:21 Hello ladies and gentlemen! +20:15:35 IMHO the content needs a little polishing (feels a bit too "I2P to the rescue!") +20:16:03 As for where on the site, I'm still not quite sure where to fit this in +20:16:05 str4d, was due march 1, can you give us a new date for getting this on to the website? +20:16:45 The "goal" of this item was to do something better than the current middle-column of the front-page and the supported applications page +20:18:02 zzz, I can put the page up at a URL +20:18:42 are you and sadie_i2p on the same page on what this work item is? sadie added this to the todo list at ccc +20:20:29 It +20:20:45 's a start, but we still need to figure out the broader information architecture +20:20:57 what it is we are actually trying to convey with the homepage +20:21:42 ok so give me a date for the first part +20:21:49 please +20:22:12 I will migrate the use cases document to the website by the end of this week +20:22:42 And a further status report at the next meeting on the homepage rearchitecture +20:23:04 ok great, hopefully you and sadie can discuss the details on the larger goals of fat and passion. +20:23:39 comraden to edit / polish / enhance / post I2P story by end of February +20:24:13 anybody know what comraden1 is up to? I need the edited draft back from him, then I want to take one more pass at it +20:25:00 this was due on the website monday +20:25:30 new date is April 1 +20:25:59 ok. i need the draft back from him in a couple weeks then +20:26:14 zzz: Link to present story draft? +20:26:39 what's on zzzi2p is still the latest. I don't want to make any changes while comraden1 has the "master" +20:26:53 ok moving on +20:27:09 tickets: Sadie to review, make recommendations or possibly start managing them (by when?) OPEN - new date mid-Feb. (?) +20:27:09 Ok. +20:27:30 sadie_i2p, how's this big task going? +20:28:06 ugh +20:29:12 need a little more than just ugh :) +20:29:14 It was a sizeable task :P +20:29:35 str4d and I have talked about weekly ticket meetings +20:29:56 that could be more feasible than some one-time 'review' +20:30:06 I thought I brought this up at an earlier meeting, but in case I didn't: I added an "open" status to Trac, to denote tickets we devs have seen but there is no one assigned or no particular status. +20:30:26 My goal of that was to differentiate those tickets from actually-new tickets +20:30:26 yes it would +20:30:26 sadie_i2p, have you gotten into it enough to make any recommendations on how we are managing tickets? +20:31:08 So the pile of "new" tickets is a darn sight smaller now I've kicked the ones we opened ourselves +20:31:15 at this point my best recommendation is weekly check in and triage +20:32:34 +1 +20:32:34 ok. are we ready yet to schedule the first meeting or is there more organizing to do first? +20:33:28 I'm still travelling, so I'd prefer to wait until next week +20:33:46 ok. if you haven't scheduled anything before the April meeting, we will ping you then +20:34:05 str4d Android 0.9.24 release by Feb 7, TODO list collated by Feb. 26 +20:34:21 seems like you're behind on those :) +20:34:28 Heh +20:34:34 new dates? +20:34:37 Both of those failed miserably, because PhD thesis +20:34:55 (which I *finally* got submitted mid-Feb) +20:35:04 I'm working on cutting 0.9.24 as we speak +20:35:06 woot. +20:35:10 (on sloooooow laptop() +20:35:14 ) +20:35:16 and the todo list? +20:35:31 Todo list collation will happen in the next few days +20:35:41 ok, we're going to hold you to it +20:35:51 heh :P +20:36:01 str4d and zzz to review VRP ticket by Feb 12. I did my side. +20:36:06 It's mainly just going through the in-repo todo list and looking for things missing from my personal todo list +20:36:14 new date for that? +20:36:20 Re: #1119, I'm just now seeing zzz's latest comment from 3 weeks ago. I never received an email nor have I been receiving emails from github or other things over the past few weeks to @mail.i2p/@i2pmail.org. +20:36:32 I'm seriously wondering if postman's email service is having problems. +20:36:37 Another thesis casualty. I'll read through it this afternoon after 0.9.24 is out +20:36:46 I may have to switch email :/ +20:36:49 ok great +20:36:49 anonimal, yah, I have had serious issues lately too (lots of email getting bounced) +20:37:03 believe it or not, I think that's all for 1) +20:37:11 and 2) +20:37:17 (since about Feb 6ish) +20:37:22 zzz: I'll read your comments more in-depth and rewrite the VRP. +20:37:28 3) Prep and schedule for roadmap meetings http://zzz.i2p/topics/2021 +20:37:33 Wait! +20:37:45 ok, sorry, anything else on 1 or 2? +20:37:45 For 1): decision on H1? +20:38:06 The decision on H1 was moved to 1) from what I remember. +20:38:41 Or not, either way I think we'll cover it today. +20:38:47 at the last meeting, we decided we would wrap up the VRP and h1 discussions at the roadmap meetings march 4-6 +20:39:11 K. +20:39:23 I just schedule those, we're going to do them tomorrow and sunday at 3 PM UTC. anonimal can you make either of those meetings? +20:39:30 Woo, that gives me a chance to review :P +20:41:08 so that takes us to 3) +20:41:11 as I said +20:41:19 I just schedule those, we're going to do them tomorrow and sunday at 3 PM UTC. +20:41:21 zzz: Eek, saturday is kovri's whopping two hour minimum 6pm UTC meeting. +20:41:21 * anonimal thinking +20:41:23 zzz: How long do you think saturday's meeting will run to? +20:41:33 does everybody have to care about kovri meeting here? +20:41:40 our meetings will be friday and sunday. no saturday. +20:41:46 or it can be sorted out privately? +20:42:05 I propose we do VRP first thing in the sunday meeting. ok? +20:42:06 * anonimal lost track of days +20:42:11 I can do Sunday. +20:42:16 Ok, sounds great. +20:43:00 these are going to be informal meetings, reviewing where we are at and where we want to go +20:43:11 the goal is to set a roadmap for the rest of the year at least +20:43:22 the second meeting may be more structured +20:43:46 I'm kindof stuck on what I should be doing next and for the rest of the year. so these meetings are vital to\ +20:43:52 setting the direction for me +20:44:08 Mmmk +20:44:15 K. +20:44:37 so friday will be more informal review or priorities. Sunday we'll start with h1/vrp, then move to really nail down the roadmap for .26-.29 +20:44:47 anything else on 3) +20:45:31 moving on to 4) +20:45:39 4) Code of Conduct proposal (Sadie) http://zzz.i2p/topics/2015?page=2 +20:45:56 i see she's now proposed doing something similar to debian +20:46:00 ah back just in time +20:46:12 anybody have any thoughts on the debian coc? +20:46:48 dedian is not an anonymous network +20:46:56 * str4d pulls up the link +20:47:05 orignal_, no, but it is FOSS +20:47:08 but what's your thoughts on their CoC orignal_ ? +20:47:17 people comes to I2P for different reasons +20:47:33 IMO, it's a little limp and I'm not sure how anything is enforced. +20:48:02 zzz, their CoC is suitable for them since it's an established project with history +20:48:04 sadie, what do you like about the debian CoC? +20:48:14 I2P is completely different +20:48:32 it seemed to provide a good basic structure for us to start with at least +20:48:40 orignal_, and I2P's >10-year history doesn't make it an established project? +20:48:45 sure, we're different, but we are indeed an established project with history +20:48:51 the last things people come here to listen this HR's BS again +20:49:31 I dont see what the reasons have for coming to a project has to do with the standards for how they should behave once they get here +20:49:41 HR? +20:50:31 I am looking for examples that are simple and to the point - +20:50:31 so perhaps not the best, but somewhere to start +20:51:29 do we think the debian one is the best place to start, or would the monero be better +20:51:36 str4d, unfortunally not +20:51:51 orignal_, "people != developers", once again. +20:51:53 compare how many people use Debian and I2P +20:52:11 donn't try to copy a big guys, you are not at that league yet +20:52:12 We can't conflate users with developers. +20:52:21 I think if we can pick the one closest to our goal, then we can ask some people to work on editing it to fit our situation +20:52:42 That would be like saying "anyone who installs Debian OS cannot say anything we don't like" +20:52:42 That is *not* what the point is here +20:52:53 And therefore, userbase does not matter for this discussion +20:52:54 monero has a very good one as well - if this is better of the two I have no objection +20:53:21 zzz, CoC is a HR's stuff +20:53:21 nothing else +20:53:28 opinions from others on debian vs. monero ? +20:53:44 + Monero +20:53:49 orignal_, what do you mean by "HR"? +20:54:07 HR = human resource +20:54:24 moneros is shorter than debian, so I guess it's easier to start small +20:55:13 do we have any volunteers to mark up the monero CoC with proposed changes and come back with it next month? +20:55:18 zzz, I like the essence of the Debian one, in that it covers a lot of what I think we care about (e.g. point 2 would have been very useful recently) +20:55:26 or the debian one +20:55:28 my opinion again, it's a time for it yet +20:55:40 we don't have to decide now on debian vs monero +20:55:48 orignal_, we got your message loud and clear, thanks +20:55:59 And it isn't too prescriptive +20:56:13 no decisions made. we're just discussing. +20:56:40 we can use what is most applicable from both +20:56:43 Re: CoC, +20:56:56 I also like point 6 - that in responding to issues, the responder should also be respectful of the CoC +20:57:03 https://github.com/monero-project/kovri/blob/master/doc/CONTRIBUTING.md +20:57:09 Also includes beautiful Monero governance process graphic. +20:57:30 zzz: re: draft -- I've been hit with an increase of crap at work and I'm dealing with a family member who went back into remission, so the history draft got put on the back burner. sadie_i2p mentioned 2016-04-01 as the new date which I'll try to meet +20:57:30 Ooh, pictures! +20:57:48 zzz: apologies for being out of the loop for a few weeks! +20:58:06 str4d zzz: Yeah, and I'd be willing to patch the contributing guide to suit java i2p. +20:58:52 Hi comraden1, I'm posting something to the story of i2p page for review. +20:59:30 i'll volunteer +20:59:58 anonimal: hey thanks :) if it's on forum I'll get to it next time I hop on. Feel free to pm it to me or reach out on clearnet +21:00:05 ok, excellent. Sadie_i2p and anonimal, can you come back with a recommendation at next month's meeting? +21:00:20 sure +21:00:25 comraden1, thanks for the update, sorry to hear about the family issues +21:00:31 anything else on 4) ? +21:00:40 * zzz warms up the baffer +21:00:48 anything else for the meeting? +21:00:54 yes, writing CoC for somebody seems a better work +21:01:13 Yes, though because i2pmail is problematic lately, sadie_i2p and I should try to chat over IRC if possible. +21:01:21 No, nothing else for meeting from me zzz. +21:01:52 orignal_, please do not interrupt our meeting with snide comments about kovri. It went way too far last month and I promised I wouldn't let it happen again +21:02:07 did I? +21:02:41 * zzz *bafs* the meeting closed +21:02:45 thanks everybody diff --git a/i2p2www/meetings/logs/243.rst b/i2p2www/meetings/logs/243.rst new file mode 100644 index 00000000..fc42166b --- /dev/null +++ b/i2p2www/meetings/logs/243.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 3, 2016 @ 20:00 UTC +========================================== + +Quick recap +----------- + +* **Present:** + +i2p-devs, diff --git a/i2p2www/meetings/logs/244.log b/i2p2www/meetings/logs/244.log new file mode 100644 index 00000000..a5136871 --- /dev/null +++ b/i2p2www/meetings/logs/244.log @@ -0,0 +1,320 @@ +15:00:05 0) hi +15:00:23 1) structure for these meetings +15:00:32 2) roadmap discussion +15:00:37 0) hi +15:00:41 hi +15:00:54 hi +15:01:02 hi! +15:01:27 what's up? +15:02:18 please review the thread at http://zzz.i2p/topics/2021 and the current roadmap at http://i2p-projekt.i2p/en/get-involved/roadmap +15:02:27 1) structure for these meetings +15:03:22 should we go straight into the roadmap or should we talk about high-level priorities first? +15:03:53 I'd go with the latter first +15:04:41 ok, so in the thread, I threw out two priorities - grow the network, and increase security +15:04:55 how do those sound as high-level principles? +15:05:25 let's first decide what's important +15:05:32 They sound as expected, I think +15:05:48 "grow the network" should be in the broad meaning, though +15:05:57 I think those are great as broad themes +15:06:03 anonimal threw out a whole bunch more in the thread, but that wasn't really what I was going for +15:06:13 increasing security should be always the most important imho +15:06:28 other principles we should consider as we review the roadmap? +15:06:28 What IMHO we need to do here is figure out what those actually mean in terms of potential deliverables +15:06:40 So "grow the network" should also mean "increase research attention" +15:07:00 grow the network means a huge variety of stuff - see the thread +15:07:09 EinMByte, yah, I think I might have mentioned that in the thread +15:07:36 we'll figure out what these mean shortly. at this minute let's agree on whats important. +15:07:58 Usability is of big importance to me, and IMHO feeds into the above two areas +15:07:58 everything is possible if we keep growing. once we stop growing we are dead +15:08:05 agreed str4d +15:08:41 More immediately in terms of increasing our userbase, and more long-term in terms of increasing our public exposure, ease of use by researchers etc. +15:09:11 Note also that growing is the only way to attract researchers +15:09:25 more users bring more devs and more researchers and more content and and and +15:09:37 Large networks are generally more interesting to study +15:10:05 So I think we call all agree on those 2 priorities +15:10:16 the bulk of our growth in the last year has been from vuze. Which is great but I'd love to have more 'native' growth also +15:10:43 but maybe growth in embedded apps, or focusing on applications in general, is the easiest path to growth +15:10:48 Yep +15:11:04 zzz: For a lot of people, it's easier to use an application that runs I2P in the background and handles the configuration for them +15:11:12 hi - a little late to the party +15:11:20 hi sadie glad you made it +15:11:23 That IMHO will come from usability improvements for both the UI and APIs +15:11:42 The latter we have already been working on in various threads +15:11:48 in some ways, it's the apps that are the UI experts, let them bundle i2p and expose (or hide) it as they see best +15:11:58 Mmm +15:12:08 str4d: That's a different solution to the same problem, yes. And I like it more because bundling I2P with everything doesn't scale IMHO +15:12:30 That is kinda the approach I was taking with Android +15:13:04 There needs to be a way to ensure that people don't have an I2P instance for every application +15:13:12 ok, anything else on 1) or should we move on to looking at the roadmap itself? +15:14:00 I think everyone here appears to be in rough agreement +15:14:08 (no dissent at least :P) +15:14:14 let me copy in the lines from the thread. Not as gospel, just for reference +15:14:25 Grow the Network +15:14:25 Includes: Marketing, joint projects, bundling more stuff, helping others bundle i2p, usability, website improvements, more translations, talks and presentations, articles and stories, UI, Android, Android apps, better GFW evasion, orchid, more libs and tools for client devs, better support for huge websites, supporting alternative router dev, alliances, speedups and efficiency, capacity, increasing limits, getting in +15:14:25 to Debian, ... +15:14:25 Increase security +15:14:25 Includes: Crypto migration, subscription protocol, new transport protocols, pluggable transports, LS2, NTCP2, new DH, key revocation, key storage, code review, sybil, bug fixes, naming, SSL, ... +15:14:46 ok, let's move on to 2) the roadmap itself +15:15:10 url is http://i2p-projekt.i2p/en/get-involved/roadmap +15:15:50 .25 is pretty much done, release in about 10 days, so let's look at the next 4 releases 26-29 for this year +15:16:00 which should carry us thru to ccc +15:16:15 If something is under 2017, e.g., does that mean we start looking into it only then, or does that mean we start the implementation at that point? +15:16:41 In terms of things we *need* to do, I'd rank the crypto migration and sybil work as high up there +15:16:42 1mb, we certainly do want to get started on big 2017 things now, like new crypto/dh, ntcp2, etc +15:17:04 Also, eclipse attacks are a problem right now, IMHO +15:17:05 so the roadmap could include prepatory work for those +15:17:23 EinMByte, yah, I was bundling that under Sybil +15:17:36 The whole midnight rotation idea doesn't work and there should be better alternatives, I suppose +15:17:52 agreed +15:18:05 str4d: Sure, it's reasonable to classify them as the same type of attack +15:18:44 EinMByte, I discussed this with a few people at RWC +15:18:48 Got some thoughts, but hard to discuss right here +15:18:51 zzz: So if we want to get started on NTCP2/... by 2017 we will need to plan preliminary work +15:18:58 right 1mb +15:19:02 Yep +15:19:20 I want to have planning and research on the roadmap :) +15:19:28 here's the issue. I should be working on 26 right now and I don't know what's in it +15:19:39 is it possible to add random padding to existsing NTCP? +15:20:01 orignal_, not that I recall, but check the NTCP2 thread +15:20:02 so let's spend 10 minutes planning 26, then we can move to the longer term +15:20:13 k +15:20:14 tell me what I should be doing today +15:20:30 True, let's focus on that first +15:20:34 ok let's see what's on the 25 list that didnt happen +15:20:50 wrapper didnt happen, kytv is awol +15:20:54 "crypto enhancements" is pretty broad +15:21:12 what actually happened on crytpo enhancements were some 25519 speedups +15:21:34 so the .25 list all actually is in there except wrapper +15:22:00 but there's more to do on sybil so lets keep that on the 26 list +15:22:08 Great +15:22:25 We bumped GMP 6 to .26 because of the need for more testing +15:22:35 what else on the 26 list now should be in there or moved +15:23:05 Eventually preventing sybil will probably be a lot of work, so it seems long-term to me +15:23:10 (in the sense that we need a good literature review first) +15:23:15 orignal, yeah, ntcp w/ padding is ntcp2 +15:23:21 EinMByte, the Sybil detection tool isn't used for anything yet, that is where more planning is needed :) +15:23:49 hottuna4 is unavailable for a month, not sure when that month is up, so gmp6 may or not make it into 26 +15:24:02 K +15:24:37 Subscription protocol improvements for addressbook: that is something that would be very good to add in ASAP, so old Dest owners can migrate to Ed25519 +15:24:37 I think CRLs don't really need a question mark +15:24:47 But how long will that actually take to do? +15:25:14 we'll need some status update from tuna soon, I expect the deadline for propping big stuff for 26 would be late march / 1st week of april +15:26:10 * str4d still doesn't quite understand the CRL stuff, could zzz expand? +15:26:14 25 will have ability to read crls from disk, so we can include in the update +15:26:35 but thats not so helpful because in an update we can just remove the cert and that does the same thign +15:26:56 so to get crls out to ppl w/o having to do an update, we would put them in the feed +15:26:57 I'm just trying to figure out the use case +15:27:09 use case is somebody gets compromised +15:27:20 Do we still not do cert pinning? +15:27:30 no +15:27:56 so i've done 90 % of it and just need to stick the crl into the namespace +15:28:46 pinning is tricky and dangerous +15:29:05 crypto cat did the 'pinning suicide' +15:29:17 where they were pinned but an intermediate changed +15:30:49 i don't think pinning replaces cls +15:30:51 crls +15:31:21 crls not just for ssl, there's reseed and update keys +15:31:58 can we keep crls on the list for 26 then? it's almost done +15:32:20 What I'm concerned re: pinning is that someone could do e.g. a Quantum Insert-like thing to redirect a reseed domain name, and just put up any valid SSL cert satisfying the domain name requirement, and the routers will accept it +15:33:05 And re: CRLs, if we use that to disable a particular certificate, what does that certificate get replaced with? +15:33:25 nothing. in the next release there would presumably be a replacement +15:33:45 This is getting a bit far into the weeds +15:34:07 I think where I was going is we need to think this over a bit more +15:34:24 ok so let's keep crls for 26 but let's discuss the details on it in the next week or two +15:34:30 as it's not 100% clear +15:34:38 moving on +15:34:42 what else ont he 26 list +15:34:43 mmk +15:34:50 ok +15:35:08 subscription protocol +15:35:28 this is the key for crypto migration of sites +15:35:40 hosts.txt replacement or what do you mean? +15:36:22 yes this is the hosts.txt as a feed thing, with like foo.i2p=b64#sig=b64#cmd=alt ... +15:36:26 EinMByte, amending the addressbook subscription protocol with signed key-value metadata +15:36:49 proposal is pretty set, but on hold for 18 months or so +15:37:07 Sure, although wouldn't the size of the hosts file grow too large +15:38:02 Maybe add a since parameter, to exclude all hosts inserted before some given time +15:38:07 (to avoid downloading the whole list even if it's not required) +15:38:22 this was originally part of the crypto migration plan but it was hard and wasn't the most important part +15:38:49 but it's the main thing remaining on crypto migration of signatures +15:39:26 EinMByte, we kinda have that already with etag +15:39:28 this is another one of those things that's proposed with a lot of specifics, but haven't quite got agreeement and so havent started +15:39:42 str4d: Is it used, though? +15:39:46 EinMByte, yes +15:40:00 Oh, nvm. in that case +15:40:03 This would be no different to the current setup +15:40:20 so we'll on the 26 list and start on it asap. not sure if we can get far enough into it for 26 but I'll try. we need to review the thread on zzz.i2p +15:40:22 but instead of domain name entries never repeating, they would now repeat in the "stream" +15:40:42 Is there a particular reason why we need to keep the weird format, though? +15:41:05 It would seem easier to me if we just used something standard +15:41:06 maybe. compatibility with old clients. but we should review and decide for sure if that's important +15:41:20 none have us have looked at this in maybe a year +15:41:28 so we'll dust it off and take a looko +15:41:32 zzz: Compatibily could be handled by also providing the old hosts.txt file for a while +15:41:41 There's also the broader issue of what to do with e.g. all the "lost" names +15:41:53 But that is outside the current discussion +15:41:57 yup. we would also need to get the other impls involved +15:42:18 str4d: I think that's something to decide on when we get a new naming system (if we ever do) +15:42:26 For now, I want some way for currently-active domains to update their dests +15:42:26 ok, it's staying on the list for 26 for now. next on the list - sybil stuff +15:42:45 can we make sybil be automatic? Have you all read the philip winter paper I hope???? +15:42:50 And the sooner we get the core code in, the sooner we can turn it on in a year or so +15:43:50 zzz: What paper? I missed something clearly +15:44:27 check @__phw on twitter for link +15:45:02 we are working with him thanks to a sadie introduction at ccc +15:45:03 zzz: this: http://arxiv.org/pdf/1602.07787v1.pdf? +15:45:27 if it was published in the last coulple weeks, thats it +15:45:59 Well, it's an eprint from February this year +15:46:09 i don't think we're ready for automatic. they arent really either +15:46:22 they just spit out an email once a day to the dirauths +15:46:36 it's all heuristic and magic on both sides +15:46:49 So he probably put the eprint online after it got published +15:46:57 so I'd like to push automatic stuff out to later in the year +15:47:07 EinMByte, 25 Feb is the version I have +15:47:14 zzz: So how exactly would that work in a decentralized setting? +15:47:44 We need to do things from the bottom-up instead of the top-down +15:48:06 ie. each router would need to include "potential Sybil candidates" in the peer profiles +15:48:13 EinMByte, I don't know. it's hard +15:48:20 based on e.g. online times etc. +15:48:30 Detecting sybil attacks is doable I think, preventing them based on that detection is very hard in a decentralized network +15:48:30 But I like the challenge +15:48:34 we also need gravy who is working on a centralized redo of his setup +15:48:43 There is also the possibility of having some kind of more centralized setup +15:48:45 Yah, that +15:48:45 str4d: At that point you need to start assigning trust to each router +15:48:52 which itself would be a whole anti-sybil system +15:49:07 And having routers subscribe to a list of potential sybils +15:49:07 kinda like the dagon proposals +15:49:09 EinMByte, that is basically what peer profiles are now though +15:49:31 where "trust" is currently defined as "reliably routed well for me in the past" +15:49:42 str4d: Yes, and they've caused a few attacks so far :) +15:50:15 Yep +15:50:23 Also, peer profiles don't really allow you exclude a peer from the network +15:50:31 Sybil prevention would sort of allow that +15:50:35 Peer profiling and peer selection is another of the things I think needs prioritisation +15:50:46 EinMByte, they *can* +15:51:01 so i propose to change the 26 sybil item to 'continued improvement' but move the 'automatic' part to later +15:51:01 Not right now +15:51:11 I'm just saying that is where we would put it +15:51:34 str4d: Yes, that's possible. +15:51:37 (in terms of putting Sybil detection and more advanced techniques into I2P's lexicon and architecture) +15:51:53 In any case, I would not drop the decentralization. It's the nicest part of I2P imho +15:52:14 Yep +15:52:27 (and centralization also leads to various practical attacks anyway) +15:52:43 lets move on. streaming improvements? not sure what that is, maybe just perennial 'make it better' item +15:52:49 zzz, yep, we can continue to work on that routerconsole page, and then hook it into the peer profiles and selection once we decide on a strategy +15:53:00 i can't think of what there is to do specifically on streaming. anybody? +15:53:01 Sometimes adding a central authority can make your security proof easy, but cause security failure in practice +15:53:20 Research and optimizations would be nice +15:53:28 zzz: Any obvious improvements we could make there? +15:53:30 That would be a good candidate for external research +15:53:46 we really need a better test setup +15:53:51 str4d: I agree. +15:53:55 add delays / drops, reorder, etc +15:54:04 We should probably extend our "open research questions" page with that and other stuff +15:54:40 i don't have much blue sky things on my list of streaming stuff. it needs to to be test-result-driven +15:54:50 There may be more improvement in the allocation of tunnels? +15:55:05 zzz, there's some GH project that simulates "The Internet" with containers that can do that IIRC +15:55:08 so how about we make this item be 'streaming test harness' +15:55:17 Dunno how easy it would be tho, we would need a new JVM per container :P +15:55:25 EinMByte, mmm +15:55:48 str4d: shadow could be used, I think. Not sure if it could be integrated with Java but it's on the kovri TODO list +15:55:52 That's not really streaming tho, that is at the datagram level +15:56:22 the tunnel allocation thing is psi's idea to have the client pick tunnels +15:56:34 str4d: Yes, I suspect there's more to optimize this +15:56:46 zzz: I don't really think users are the best optimization algorithms, but maybe +15:57:10 it's a violent corruption of our layering, and I don't see any way to do it. but that's what psi is proposing +15:57:19 ... or probably "client" does not mean user +15:57:32 client == client-side of i2cp +15:57:44 The thing there is +15:57:54 Tor does provide this ability via their Control Socket +15:57:58 Ok so it does mean that +15:57:59 And it is very useful for researchers +15:58:10 But they also have a much flatter architecture +15:58:19 Whereas we silo different clients from each other via I2CP +15:58:31 zzz: I'd expect the router to have more relevant information. The client could pass any additional requirements +15:58:41 we also have psi's lua hooks for researchers, that never got merged (either in java or kovri), but is still an option +15:59:14 see right now the client side doesn't even know about tunnels, so it certainly doesn't have any ability to pick them +15:59:16 Speaking to nickm at RWC, he said it was much easier for Tor to maintain a Control Socket interface than a plugin system +15:59:17 I know that shadow is being used in practice by researchers +15:59:22 Lua, I don't know +15:59:55 zzz: So probably the same thing can be achieved by passing the relevant information over I2CP? +16:00:17 1mb, yes, but it would be really fugly +16:00:44 We could always restrict it with a -research flag or something +16:00:54 (in router.config) +16:01:06 That way most users are not exposed to the fugly +16:01:13 kovri/i2pd don't have those rigid API barriers between client/router yet, it's easier for the +16:01:20 *them +16:01:28 And we can define ".research" from the start to mean "We reserve the right to change these APIs" +16:01:44 ie. researchers would need to use the .research flag along with a particular version +16:01:57 Back to the actual topic of discussion: +16:01:59 zzz: Re: tunnels. It depends. I think it would make sense to pass information about the intended usage of the tunnel. +16:02:20 (FYI this meeting will go 25 more minutes max, to be continued sunday) +16:02:33 zzz: It's mainly easier for us because shadow is written in C, I think +16:02:42 I think this should be pushed into the "needs more research" category +16:02:44 the trouble is its not just your tunnels that need to be picked but the far-end's tunnels +16:02:48 Ok. Let's move on then. +16:03:08 ok that's all that's on the 26 list now. What should be added? +16:03:11 zzz: Doesn't the far-end handle that +16:03:36 no, we source-route (i.e. pick the far-end lease out of it's leaseset for his inbound) +16:04:08 look at the 27-29 list. what should be pulled in to 26 if anything? +16:04:44 I want to start getting the prep work done for new LSs and the netdb +16:04:46 here is where all the 'initial work on xxx for 2017' is, but also lots of 2016 stuff +16:05:23 zzz: I misunderstood what you meant with far-end, nvm +16:05:31 The sooner we get that settled down and into the codebase, the sooner the network will have broad support for it +16:06:42 Note that we (kovri) want specifications +16:06:52 Otherwise it will be hard to keep up with the implementation +16:07:31 sure. anything that's a new specification, we need to all work on together +16:07:36 str4d: Let's start by listing what LS2 should actually support +16:07:53 (if that hasn't already been done) +16:09:40 basically ls2 is only a couple of things +16:09:59 add some space for flags +16:10:09 and enable future crypto +16:10:52 but i have all those proposals about better multihoming, plus grothoff-like service lookup +16:11:00 anycast +16:11:01 Do we have specific list somewhere for reference? +16:11:11 it's pulled together on zzz, sec +16:11:23 EinMByte, I'm slowly working on pulling all that together on the website +16:11:41 can we make that faster str4d ? like next week or two? +16:11:47 That should go into the .26 list +16:11:50 Hmm +16:11:53 Possibly +16:11:59 I need moar eyes on it +16:11:59 without the proposals on a simple list this is way too hard +16:12:08 str4d: Great. Actually for some of these things a wiki-functionality would be useful +16:12:24 (idea is that it would go faster) +16:12:48 for starters we need a list +16:12:50 EinMByte, exactly +16:12:56 lets not boil the ocean here +16:13:11 I'm trying to move from requiring backend HTML to (currently) rST +16:13:31 I need people to look over what I have to check that a) it is usable and b) it doesn't lose anything we currently have +16:13:39 Currently it is applied to the spec docs only +16:13:40 let's put the proposal thing on the list for 26 and we'll talk later about what that means. But we need forward progress on it asap. +16:13:55 But the moment that is solidified, extending it to proposals is trivial +16:13:56 i want them on the website. i don't care what form. +16:14:46 I'm willing to review proposals, but it happens sometimes that I just don't find any text +16:15:10 (some things on the website are sort of hidden, I think) +16:15:37 right +16:16:05 we need to move stuff from zzz.i2p to the website in some sort of organization +16:16:13 str4d: Moving from HTML to something which can be easility converted to various formats is a good thing +16:16:28 zzz: Yes, absolutely +16:16:35 EinMByte, what I need reviewed is in i2p.www.str4d +16:16:36 Maybe a fixed process for all proposals +16:16:57 ok. it's on the list for 26. details to follow. str4d get to work. i wouldn't expect a lot of feedback. Just come up with a new system and we will all fall in line +16:17:02 and on http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ +16:17:04 EinMByte, if you want to work with me on nailing that down, I could get that finished maybe by .25 +16:17:23 what else for 26? we gotta wrap this up +16:17:36 ( EinMByte, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec specifically) +16:18:14 this is very short term stuff. I need to know what to do on monday +16:18:27 last call for 26 +16:18:41 I think the subscriptions stuff will take a while +16:18:49 So I'd be happy with that being the main thing +16:18:52 agreed. +16:19:54 ok. meeting on sunday same time. we will start with vrp/h1. please review ticket 1119 in advance. after that we will talk about 27-29, time permitting. +16:20:06 str4d: Any of those that you think require most attention? +16:20:27 we can also briefly circle back to 26 on sunday if necessary +16:20:43 EinMByte, basically deciding whether the format for writing proposals is usable, and whether it limits what ends up on the website (in either HTML or TXT format) +16:20:45 so agenda on sunday will be 1) vrp/h1/1119; 2) 26; 3) 27-29 +16:20:57 thanks everybody +16:21:25 * zzz *bafs* the meeting closed +16:27:50 str4d: It is probably OK as long as it can be coverted to most other formats :) diff --git a/i2p2www/meetings/logs/244.rst b/i2p2www/meetings/logs/244.rst new file mode 100644 index 00000000..d38c3462 --- /dev/null +++ b/i2p2www/meetings/logs/244.rst @@ -0,0 +1,9 @@ +I2P dev meeting, March 4, 2016 @ 15:00 UTC +========================================== + +Quick recap +----------- + +* **Present:** + +i2p-devs, From 07464624ae604ca006534ef20042aab272db1c91 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 5 Mar 2016 15:48:19 +0000 Subject: [PATCH 112/114] Update present lists --- i2p2www/meetings/logs/242.rst | 29 ++++++++++++++++++++++++++++- i2p2www/meetings/logs/243.rst | 10 +++++++++- i2p2www/meetings/logs/244.rst | 7 ++++++- 3 files changed, 43 insertions(+), 3 deletions(-) diff --git a/i2p2www/meetings/logs/242.rst b/i2p2www/meetings/logs/242.rst index dad65f3f..b40630e4 100644 --- a/i2p2www/meetings/logs/242.rst +++ b/i2p2www/meetings/logs/242.rst @@ -6,4 +6,31 @@ Quick recap * **Present:** -i2p-devs, +allyourbase, +anonimal, +C0B4, +cacapo, +comraden1, +eche|on, +EinMByte, +hottuna, +Hummingbird, +Irc2PGuest39432, +Irc2PGuest76545, +Irc2PGuest95462, +IrcI2Pd743, +JIa3apb_KaraHoBu4, +lazygravy, +nda, +orignal, +psi, +sadie_i21, +str4d, +supervillain, +The_Tin_Hat, +trolly, +xcps, +Yankee, +z3r0fox, +zab__, +zzz diff --git a/i2p2www/meetings/logs/243.rst b/i2p2www/meetings/logs/243.rst index fc42166b..35465d36 100644 --- a/i2p2www/meetings/logs/243.rst +++ b/i2p2www/meetings/logs/243.rst @@ -6,4 +6,12 @@ Quick recap * **Present:** -i2p-devs, +anonimal, +comraden1, +eche|on, +hottuna4, +orignal_, +sadie_i2p, +str4d, +Yankee, +zzz diff --git a/i2p2www/meetings/logs/244.rst b/i2p2www/meetings/logs/244.rst index d38c3462..702e4c5f 100644 --- a/i2p2www/meetings/logs/244.rst +++ b/i2p2www/meetings/logs/244.rst @@ -6,4 +6,9 @@ Quick recap * **Present:** -i2p-devs, +EinMByte, +orignal_, +sadie, +str4d, +xcps_, +zzz From 26f90f9e7ae4c0a367d5d12cf0c61d6b2016eabb Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 5 Mar 2016 15:56:42 +0000 Subject: [PATCH 113/114] Wrap long lines in {% highlight %} blocks --- i2p2www/static/styles/duck/default.css | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css index 99da77fb..60129146 100644 --- a/i2p2www/static/styles/duck/default.css +++ b/i2p2www/static/styles/duck/default.css @@ -395,8 +395,12 @@ div#content .inner ul.DREAD { * Additions to syntax.css */ -.highlight { - overflow: auto +.highlight > pre { + white-space: pre-wrap; /* CSS-3 */ + white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */ + white-space: -pre-wrap; /* Opera 4-6 */ + white-space: -o-pre-wrap; /* Opera 7 */ + word-wrap: break-word; /* Internet Explorer 5.5+ */ } /* From 88a4899611db1cc06d3eb92b73044a68d0934228 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 5 Mar 2016 15:58:45 +0000 Subject: [PATCH 114/114] Fix present usernames --- i2p2www/meetings/logs/242.rst | 2 +- i2p2www/meetings/logs/243.rst | 2 +- i2p2www/meetings/logs/244.rst | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/i2p2www/meetings/logs/242.rst b/i2p2www/meetings/logs/242.rst index b40630e4..9934d0c3 100644 --- a/i2p2www/meetings/logs/242.rst +++ b/i2p2www/meetings/logs/242.rst @@ -32,5 +32,5 @@ trolly, xcps, Yankee, z3r0fox, -zab__, +zab\__, zzz diff --git a/i2p2www/meetings/logs/243.rst b/i2p2www/meetings/logs/243.rst index 35465d36..b0b5b446 100644 --- a/i2p2www/meetings/logs/243.rst +++ b/i2p2www/meetings/logs/243.rst @@ -10,7 +10,7 @@ anonimal, comraden1, eche|on, hottuna4, -orignal_, +orignal\_, sadie_i2p, str4d, Yankee, diff --git a/i2p2www/meetings/logs/244.rst b/i2p2www/meetings/logs/244.rst index 702e4c5f..74cc0ce5 100644 --- a/i2p2www/meetings/logs/244.rst +++ b/i2p2www/meetings/logs/244.rst @@ -7,8 +7,8 @@ Quick recap * **Present:** EinMByte, -orignal_, +orignal\_, sadie, str4d, -xcps_, +xcps\_, zzz