Opened 9 years ago

Closed 9 years ago

#360 closed defect (wontfix)

Addressbook fails on base64 lookups.

Reported by: sponge Owned by: sponge
Priority: minor Milestone: 0.8.3
Component: apps/BOB Version: 0.8.1
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

If an address is provided that has the full base64 already, the lookup fails.

Example:
lookup VG4Bd~q1RA3BdoF3z5fSR7p0xe1CTVgDMWVGyFchA9Wm2iXUkIR35G45XE31Uc9~IOt-ktNLL2~TYQZ13Vl8udosngDn8RJG1NtVASH4khsbgkkoFLWd6UuvuOjQKBFKjaEPJgxOzh0kxolRPPNHhFuuAGzNLKvz~LI2MTf0P6nwmRg1lBoRIUpSVocEHY4X306nT2VtY07FixbJcPCU~EeRin24yNoiZop-C3Wi1SGwJJK-NS7mnkNzd8ngDJXDJtR-wLP1vNyyBY6NySgqPiIhENHoVeXd5krlR42HORCxEDb4jhoqlbyJq-PrhTJ5HdH4-~gEq09B~~NIHzy7X02XgmBXhTYRtl6HbLMXs6SI5fq9OFgVp5YZWYUklJjMDI7jOrGrEZGSHhnJK9kT6D3CqVIM0cYEhe4ttmTegbZvC~J6DrRTIAX422qRQJBPsTUnv4iFyuJE-8SodP6ikTjRH21Qx73SxqOvmrOiu7Bsp0lvVDa84aoaYLdiGv87AAAA.i2p
ERROR Address Not found.
lookup VG4Bd~q1RA3BdoF3z5fSR7p0xe1CTVgDMWVGyFchA9Wm2iXUkIR35G45XE31Uc9~IOt-ktNLL2~TYQZ13Vl8udosngDn8RJG1NtVASH4khsbgkkoFLWd6UuvuOjQKBFKjaEPJgxOzh0kxolRPPNHhFuuAGzNLKvz~LI2MTf0P6nwmRg1lBoRIUpSVocEHY4X306nT2VtY07FixbJcPCU~EeRin24yNoiZop-C3Wi1SGwJJK-NS7mnkNzd8ngDJXDJtR-wLP1vNyyBY6NySgqPiIhENHoVeXd5krlR42HORCxEDb4jhoqlbyJq-PrhTJ5HdH4-~gEq09B~~NIHzy7X02XgmBXhTYRtl6HbLMXs6SI5fq9OFgVp5YZWYUklJjMDI7jOrGrEZGSHhnJK9kT6D3CqVIM0cYEhe4ttmTegbZvC~J6DrRTIAX422qRQJBPsTUnv4iFyuJE-8SodP6ikTjRH21Qx73SxqOvmrOiu7Bsp0lvVDa84aoaYLdiGv87AAAA
ERROR Address Not found.

Subtickets

Change History (6)

comment:1 Changed 9 years ago by zzz

Owner: set to sponge
Status: newassigned

This is the naming service, not addressbook.
This is a BOB bug.

The hosts.txt naming service only supports 3 forms:
1) 516+ chars of B64 ONLY
2) {52 chars}.b32.i2p
3) < 516 chars, which is looked up in hosts.txt

It's the client's responsibility to pass ONLY these 3 forms to the naming service. We will not be adding any more forms to the naming service.

The BOB bug is only handling things that end with .i2p, and not stripping .i2p from 516+ char dests before handing them to the naming service, thus causing both the above cases to fail.

Also, please remove the deprecated I2PTunnel.destFromName() from BOB, and then remove the dependency from the top-level project build.xml (see the buildBOB target).

Reassigning to you. And I'm going to go make a component category for BOB.

comment:2 Changed 9 years ago by zzz

Component: apps/addressbookapps/BOB

comment:3 Changed 9 years ago by zzz

On further thought, perhaps what the user was expecting was a reverse lookup, converting the b64 destination string to a host name?

That is, of course, not provide by I2PTunnel.destFromName() or NamingService?.lookup() !!

If you want to provide a reverse lookup service in BOB, feel free, using NamingService?.reverseLookup(). Beware that that method is unused, deprecated, and slow as it is uncached. You could un-deprecate it if you want.

I don't, atm, see why that service would need to be in BOB though.

comment:4 Changed 9 years ago by sponge

Status: assignedaccepted

I'm not sure what the user was expecting, I assume the base64 returned was wanted.
Furthermore the '.i2p' is a block of code that is a guard, anything not ending in '.i2p' will be thrown out as a feature.
I think that the addressbook should be smart enough to take something that is already a base64key that's ending in .i2p and just return the base64.

As far as the I2PTunnel.destFromName() stuff, I'll look into that.

comment:5 Changed 9 years ago by zzz

I'm not sure what the user was expecting, I assume the base64 returned was wanted.

So the user wanted some code somewhere to strip the ".i2p" from his string and give the rest back to him unchanged? That's what this ticket is about? That makes no sense at all. We have all this complicated code all to strip 4 characters from a string for somebody?

I think that the addressbook should be smart enough to take something that is already a base64key that's ending in .i2p and just return the base64.

Naming service (again, this is not addressbook) is very simple. It takes a string and turns it into a Destination. {516 chars}.i2p is not a standard it supports.

If the NamingService? API gets upgraded (see proposal on zzz.i2p) it may become even more strict.

All the NamingService? does with 516+ chars is try to un-base64 it and convert it to a Destination. Frankly, it shouldn't even be doing that… the client should do that itself. Why ask the NamingService? to do that?

So I think NamingService? should be doing less, not more.

BOB is your client, you can provide whatever services you want. Handle cases however you want. But don't depend on the API (i2p.jar / NamingService?) to do everything for you. It's just an API. If you want to strip 4 characters for users, knock yourself out. Just don't ask the API to do it.

comment:6 Changed 9 years ago by sponge

Resolution: wontfix
Status: acceptedclosed

User should be stripping the i2p in their software, changing status to "wontfix".

Note: See TracTickets for help on using tickets.