Custom Query (1844 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (28 - 30 of 1844)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Ticket Resolution Summary Owner Reporter
#1318 fixed Extending SAM to Allow Creation of More Secure Destinations zzz ExtraBattery
Description

It would be great if SAM was extended so that it allows applications to make use of the new destination types introduced with I2P 0.9.12. For the extension, the SAM version could be slightly changed from 3.0 to 3.1, so that the client application is always aware of the capabilities of the bridge. The full v3.0 feature-set should be retained in v3.1.

Proposed extension:

In a "SESSION CREATE" message, if the key-value pair "DESTINATION=TRANSIENT" is used, an *optional* "DESTSIGTYPE" key is allowed, which can take any of the following seven values (where DSA_SHA1_160 is the default):

DSA_SHA1_160 ECDSA_SHA2_256 ECDSA_SHA2_384 ECDSA_SHA2_521 RSA_SHA2_2048 RSA_SHA2_3072 RSA_SHA2_4096

Alternatively the signature type code may be used as value: 0-6

First example:

SESSION CREATE STYLE=STREAM DESTINATION=TRANSIENT DESTSIGTYPE=ECDSA_SHA2_521 ID=Test

Second example (using the type code):

SESSION CREATE STYLE=STREAM DESTINATION=TRANSIENT DESTSIGTYPE=3 ID=Test

#1325 fixed SAM - Parsing of Properties mkvore ExtraBattery
Description

There was a similar problem reported in #950.

Taking a look (no testing) at the routine parseParams() in "SAMUtils.java": It seems to allow for the key to be an empty string. So this would be treated as legal:

=value =value2 =value3

There is also a mechanism that handles quoted values. It seems not to take into account that the StringTokenizer? treats multiple subsequent delimiters as one. So this:

PASSWORD="Jane   Doe" (imagine three *normal* (0x20) spaces between Jane and Doe, but Trac seems to remove them to make it harder for me to make the point, so I used 0xA0 instead)

seems to be treated as:

PASSWORD="Jane Doe"

Since there is no escape sequence, it is impossible to use a string as a value that contains a quote char and a space char later. So this:

PASSWORD="Jane " Doe"

would be rejected as illegal.

#1334 fixed RAW Datagram Handling of SAM Broken mkvore ExtraBattery
Description

I recently tried to send a non-repliable datagram to a destination registered for repliable datagrams (using SAM). I wanted to know if the datagram is delivered. I then realized that I'm unable to send a non-repliable datagram at all.

If I first create a raw datagram session in SAM "SESSION CREATE STYLE=RAW …" and then try to send a datagram using "RAW SEND DESTINATION=… SIZE=…", I receive nothing even though I listen using another raw session. With repliable datagrams this procedure works.

So "RAW" datagram handling of SAM seems to be broken.

I also realized that the SAM documentation doesn't mention how to send a datagram without port forwarding. So it would be helpful to add some info concerning the two SAM commands for sending repliable and non-repliable datagrams using the SAM client connection:

  • DATAGRAM SEND DESTINATION=… SIZE=…
  • RAW SEND DESTINATION=… SIZE=…

I used I2P 0.9.13-0 for testing this. No experimental SAM was used.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Note: See TracQuery for help on using queries.