[tor-dev] Release new version of stem

Hey,

nodens(nodens@debian.org) and me are currently packaging the new version of
onionshare for Debian and stumbled over the dependency cepa[1], what is a fork
of stem. After digging deeper into it, I found out, that the main reason why
they do so is the support for Client Auth v3 onions[2]. I really would like
not to package a fork of stem, if possible. That's why I ask, when it is
planed to release a new version of stem? It hasn't seen any release since 2019
and there are a lot of changes in master branch too. Maybe you can just
release the current state of the maint branch, that is actually what is
released as cepa 1.8.3.

I some how need to solve this till January, when Debian is freezing (not
accepting new versions).

Regards

hefee

[1] GitHub - onionshare/cepa: Python controller library for Tor
[2] don't use deprecated int_from_byte to test cryptography · torproject/stem@4e3917c · GitHub
2f3bbf64b4ce3b63160a3c56b15748ba626de4a0

Hefee:

Hey,

nodens(nodens@debian.org) and me are currently packaging the new version of
onionshare for Debian and stumbled over the dependency cepa[1], what is a fork
of stem. After digging deeper into it, I found out, that the main reason why
they do so is the support for Client Auth v3 onions[2]. I really would like
not to package a fork of stem, if possible. That's why I ask, when it is
planed to release a new version of stem? It hasn't seen any release since 2019
and there are a lot of changes in master branch too. Maybe you can just
release the current state of the maint branch, that is actually what is
released as cepa 1.8.3.

I some how need to solve this till January, when Debian is freezing (not
accepting new versions).

That is tricky as stem is not maintained anymore and therefore deprecated. There are no further releases planned and talking to atagar last time he said the master branch was not ready for release. We could think about minor point releases for the 1.8 series but those would just contain small bug fixes (like Python 3.10 compatibility) but no new features.

Hope this helps,
Georg

Hey,

That is tricky as stem is not maintained anymore and therefore
deprecated.

That is a pitty. It would be nice if you can actually make this obvious on the
git repo like "currently stem is unmaintained and therefore deprecated" and
maybe search for people in the community to take over - maybe ask people from
onionshare?
Especially as stem is still marked as the way to interact with tor via python.
Like it was done on this ml in August:
https://lists.torproject.org/pipermail/tor-dev/2022-August/014768.html

There are no further releases planned and talking to atagar
last time he said the master branch was not ready for release. We could
think about minor point releases for the 1.8 series but those would just
contain small bug fixes (like Python 3.10 compatibility) but no new
features.

Having a way to work with Python 3.10+ is still great but will not help for
our use case as onionshare using the feature of client auth v3.

regards,

hefee

···

--
Mein öffentlicher Schlüssel / My public key: E68031D299A6527C
Fingerabdruck / Fingerprint:
D256 4951 1272 8840 BB5E 99F2 E680 31D2 99A6 527C
runterladen/download:
https://keys.openpgp.org/vks/v1/by-fingerprint/
D256495112728840BB5E99F2E68031D299A6527C

> That is tricky as stem is not maintained anymore and therefore
> deprecated.

That is a pitty. It would be nice if you can actually make this obvious on the
git repo like "currently stem is unmaintained and therefore deprecated"

Hiya. Just a minor terminology correction: Stem is unmaintained but
not deprecated. The later implies that there's a replacement. There's
other options [1] but for most of Stem's features it's the only game
in town.

maybe search for people in the community to take over - maybe ask people from
onionshare?

If someone's serious about it we can talk but properly maintaining
Stem is a lot of work [2][3].

Especially as stem is still marked as the way to interact with tor via python.

As far as I'm aware it is.

Cheers! -Damian

[1] Frequently Asked Questions — Stem 1.8.0 documentation
[2] Spec compliance · Issue #97 · torproject/stem · GitHub
[3] Remove asyncio metaprogramming · Issue #77 · torproject/stem · GitHub

···

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Hefee:

Hey,

That is tricky as stem is not maintained anymore and therefore
deprecated.

That is a pitty. It would be nice if you can actually make this obvious on the
git repo like "currently stem is unmaintained and therefore deprecated" and
maybe search for people in the community to take over - maybe ask people from
onionshare?

We don't have access to the official repository on Github. We've had done it otherwise. For the taking over part it seems atagar replied already, great.

Especially as stem is still marked as the way to interact with tor via python.
Like it was done on this ml in August:
[tor-dev] TOR socket for P2P in Python

There are no further releases planned ahttps://lists.torproject.org/pipermail/tor-dev/2022-August/014768.htmlnd talking to atagar
last time he said the master branch was not ready for release. We could
think about minor point releases for the 1.8 series but those would just
contain small bug fixes (like Python 3.10 compatibility) but no new
features.

Having a way to work with Python 3.10+ is still great but will not help for
our use case as onionshare using the feature of client auth v3.

That's right. atagar: what about this: it seems you already created a separate branch with the change needed by the onionshare folks (nice!). Would you mind creating a point release (or 1.9) so the Debian folks can pick that up, including the Python 3.10 compatibility fix as well? I think that would be the easiest short-term solution to the problem hefee came up with.

Thanks,
Georg

···

regards,

hefee

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
tor-dev Info Page

Hello,

A friendly reminder that txtorcon exists and supports v3 onions, (even if developed has slowed somewhat in recent times).

It probably doesn't help onionshare a lot, as txtorcon is a Twisted-based async API so it works best with other Twisted-using code.
That said, you _can_ inter-operate with asyncio or even with threaded code if you want. However, it's not going to be a drop-in Stem replacement (and that has never been txtorcon's goal).

    GitHub - meejah/txtorcon: Twisted-based asynchronous Tor control protocol implementation. Includes unit-tests, examples, state-tracking code and configuration abstraction.

Documentation available via onion (which self-hosts on the Twisted webserver with txtorcon for Tor support):

    http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/

···

--
meejah
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Hi hefee,

There are no further releases planned and talking to atagar
last time he said the master branch was not ready for release. We could
think about minor point releases for the 1.8 series but those would just
contain small bug fixes (like Python 3.10 compatibility) but no new
features.

Having a way to work with Python 3.10+ is still great but will not help for
our use case as onionshare using the feature of client auth v3.

we've released stem 1.8.1 [1] including v3 onion services patches [2]. There'd be a pypi package soon (in aprox. 1 day) and stem's website update.

Please, let us know whether that works for you,

Cheers,

juga.

[1] Release 1.8.1 · torproject/stem · GitHub

[2] Commits · torproject/stem · GitHub

···

On 9/17/22 11:06, Hefee wrote:

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev