[tor-dev] Shortcomings of the pluggable transports specification?

[teor]

Hi Philipp,

> On 13 Jun 2019, at 09:41, Philipp Winter <phw at nymity.ch> wrote:
> 
> We are working on improving Tor's pluggable transports specification:
> <https://spec.torproject.org/pt-spec>
> 
> The goal is to make the spec useful to more people and fix issues that
> have accumulated over the years.  For more context, have a look at the
> following ticket, which we use to coordinate this effort:
> <https://bugs.torproject.org/29285>
> 
> Before changing the spec, we need to understand its shortcomings and
> what issues implementers have run into.  For those of you who have
> experience with the spec -- either Tor's version 1.0 or version 2.1
> maintained by pluggabletransports.info -- please let us know:
> 
> * What version of the PT specification and what library implementation
>  (if any) are you using?

Yawning, David, and I pointed out a bunch of issues in PT 2.0 and 2.1:

https://lists.torproject.org/pipermail/tor-dev/2017-June/012332.html

Most of these issues were present in PT 1.0, some of them were newly
introduced in 2.0.

Some of the issues were caused by tor's limited PT interface, which
we've improved recently.

Some were also caused by confusion over whether the application or the
transport should take responsibility for certain features.

I've also opened some trac tickets over the past few years. I assume
they've been triaged, and someone has an overview of which changes we
have wanted to make in the past.

> * What has your experience been with the PT specification?

I am very confused by all the different specifications and implementations.

> * How would you improve the specification?

Start by defining a scope for pluggable transports. Ruthlessly limit the
specification to a programming language-agnostic interface. Allow for
extensions to the core specification, which can be included once they are
in active use.

Document language-specific APIs separately. Or create a language-agnostic
API using some kind of binding generator. (If that results in a functional
and usable interface.)

T

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190613/a7365a9e/attachment.sig>