I talked to meejah and GETCONF SOCKSPort is only issued when it fails to use the port that was provided or the default ones. I think we could allow that and leave it up to txtorcon to query the process the right SOCKS port. That will make it easier for us to implement the automatic Tor process handling (one less thing to ask the user).
May 30 2017
May 28 2017
Here is an update, based on the profile you provided and Ricochet's:
May 17 2017
May 16 2017
Not required for this very task, however very much welcome for your Whonix interest generally.
I just checked some options and saved a draft. Let me know if you need a link or something to find it.
May 13 2017
Was the text you sent exactly the following?
May 9 2017
Correct, I receive notifications from email@example.com. The reply was indeed sent
May 3 2017
I just updated the text a bit with your feedback.
May 1 2017
On Mon, May 01, 2017 at 01:03:57AM +0000, Patrick (Patrick Schleizer) wrote:
XXX Should we use the usernames from Phabricator?
Probably not. But with higher priority, I'd leave that decision to the contributor.
I tried to reply, but here is what I got:
Apr 30 2017
dau (Felipe Dau):(Should this be discussed in another ticket?)
You can if there are additional questions, sure.
Right. From that perspective, we should probably rename the repository
to specs with a sub folder proposals.
https://gitweb.torproject.org/torspec.git/tree/proposals/115-two-hop-paths.txtFilename: 115-two-hop-paths.txt Title: Two Hop Paths Author: Mike Perry Created: Status: Dead Supersedes: 112
Or we don't use sub folders - then the file name would stay the same.
And just use a header to document the status and remaining to do.
I am just unsure if in the future it will be useful to separate them
to know what is stable/accepted/etc and what is not. Should we worry
about that later?
Let's just take our best guess. There is a lot of freedom in these options.
Apr 29 2017
Should this be moved out of proposals/?
I am neutral. If you like, go for it.
(In comparison, RFC - they keep calling them RFCs.)
Apr 24 2017
Sorry for taking a long time to open these:
Apr 18 2017
- Find a place to "officially" publish the convention (has it moved from "proposal" to "convention"?)
The original write draft for local listener standard on debian-devel seems done.
Could you please kindly close this ticket / create follow up ticket(s)?
Apr 13 2017
json is not trivially parsed in shell scripts. For shell scripts, something that can be simply evaluated would be nice. (Just echo listen_ip=xxx, so listen_ip=xxx gets set.)
Hmm, maybe I was not very clear on the explanation. I did not suggest changing the configs format (the .conf files). They should still look like something evaluable.
I did not interpret your suggestion as a change in the conf files.
What I suggested was the use of json to return the *parsed* configs to applications.
Yes, got that. That's why I wanted to point out, that json is hard to parse in shell scripts.
As a Python user (and as this would be a Python package) I would expect to get a dict with the configs to use on my application. For non-Python applications, that dict would be serialized to json because I believe that is one of the most popular formats these days with support from many languages. Also, we can offer multiple "serializers" if needed.
Yes, something that works for shell scripts would be nice.
Was that your concern?
Apr 12 2017
check_filename -> is_config_file
find_files -> find_config_files
On the other hand... I personally prefer the very at the end and to have some consistency, i.e. config_read, config_check and so forth.
Apr 9 2017
I noticed the link in the description needs to be updated. Would you change to https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt?
This class is reasonably flexible so that people are able to customize how files are found and parsed. I pretty much just wrote the API, but here is what I have in mind:
Mar 29 2017
I see. I will let you know how that goes.
Mar 28 2017
I have no idea if something like this exists. Might not as I don't know python applications doing this.
I think [zzz] is a bonus. No need to wait for it or to let it block our progress here. We got some great suggestions for our initial draft which we then implemented. I think in this case it's fair to interpret the absence of criticism and praise as an okay signal to move forward. This is probably also how things work. Some people create some convention, then just do it. If it then proves to be useful and working, it might become an official Debian standard. Neither Debian nor freedesktop want to be the gatekeepers of innovation.
Mar 26 2017
Mar 23 2017
Mar 22 2017
Right. Could you please add that text the Description part? I mean, the Description part is the part that gets actually copied over to the Debian mailing list in this case.
I'd suggest to add the link to the ticket and repo rather as a bonus. To be added somewhere at the end. We are mainly addressing the people on the mailing list. Beginning the text with two external links, I mean with...
might deter readers? Or am I over thinking this? I don't want to start painting the proverbial bikeshed.
Let me know what you think of the new PR.
Neither /etc/server-config.d nor /etc/server look like ideal choices
for folder names to me. I was hoping for better suggestions. =)
/etc/server/main.config is not so pretty. A folder with a single
config file. Why a folder then.
(I also had in mind /etc/listen/main.conf as well as
/etc/listen/conf.d/*.conf. That would be similar to /etc/dpkg. But
/etc/listen/conf.d/ would be less consistent with /usr/lib/listen.d/.)
What about as name, listen? Is this specific enough only on the topic
of listen or will it likely expand to also covering "server"?
Let's go with the following?
Added How the wrappers would be specified in the config language is yet to be invented, which will be done if this implementation path looks favorable. does that sound alright to you?
Mar 21 2017
Right. (Feel free to report a bug against http://trac.torproject.org torsocks component.)
Alright, I just made the PR with the changes we discussed. Also made minor changes to make it a bit more friendlier.
If you are using git anyhow to generate the diff, could you please fork https://github.com/adrelanos/listen-port-convention and commit? That would make the diff a lot easier to apply and read for me.
Mar 20 2017
This is a great idea!
As we discussed in , I am updating the draft.
Feb 21 2017
I waited for the Tor PR guys to get back to me but I'm pretty sure they won't at this point. I went ahead and announced it on our blog and other high traffic mail lists to get more attention.
Feb 20 2017
a) is how systemd parses systemd unit files. In that case one would have to use listen_ip= to disable listeners by lower priority configuration files.
I agree, this looks great! The only thing I noticed is that the dpkg conflict resolution reference is probably missing a :. Maybe that's why it looks like a checked check box? ([x] instead of [x]:?)
Feb 17 2017
unMessage is an anonymous communication program that uses Tor to hide metadata of participants. Its still in early development, however a major new feature such as Tor-to-Tor audio chat (the first such implementation we are aware of) has been included. Major additions like file-sharing support, video conferencing and a portable code-base mobile platforms are planned.
Our major goal is to provide a better UX and a competitive feature set to move users away from proprietary solutions that don't respect privacy. Though not ready for mass adoption yet, we encourage the more technical audience among you to go ahead try it out. We appreciate any feedback and/or pull requests.
Check us out on Github:
Feb 13 2017
@dau The Tor Project is running a series of blog posts on OS's and programs that make use of their network as part of raising awareness about them in the community. These are short articles that describe what the respective projects are about and their future goals. I want to let them know about unMessage. This will get attention and potentially attract more coders. What do you think? Check with your friend rxcomm and let me know.
Feb 3 2017
@dau That's awesome :) I was waiting for more competition in the Onion messaging space and I like that you guys are using an extra crypto layer as fallback.
Thanks for letting us know about it. I'll give it a spin and post feedback on Github.
Thank you for your interest! Don't worry too much about formalities. I like clean tickets and reorganize them if useful. Anyhow, this ticket is very much fine.
also created port to ephemeral Tor hidden services / python-stem:
Feb 2 2017
Aug 20 2016
As soon as TUF for python is packaged for Debian I will document how to install nymphemeral with it.
Background: TUF provides a secure updater framework that guarantees package and update integrity. It is now integrated in many alternative installer/updaters that traditionally had poor to no security. Using it with pip will give the same security benefits as if it was available under Debian's apt.
Feb 10 2016
I never read that a test suite is required for a package to be accepted
into Debian. Unfortunately, I don't know what the best more straight
forward guide into Debian packaging [of a python project] is.
whonix-setup-wizard is a python package maintained by Whonix.
It has only one dependency, genmkfile that is unfortunately not yet
packaged for Debian but hopefully sooner than later.
You can see there the /debian sub folder. You could copy and paste it
as a template and then modify for nymphemeral.
Debian package build instructions are included in the project's readme.
It produces a 100 % lintian (including --pedantic) warning free
package. [Lintian is the package quality checker by Debian.] And
reasonable absence of lintian warnings this is a condition for packages
to be accepted in Debian.
There surely are other ways to package python based software for Debian.
Look into a few python based software packages and download their
sources. (apt-get source pkg-name)
There is also the Debian mentors mailing list, which helps with
I suggest to try to reach out to the Debian Anonymity Tools Team for help.
Aug 12 2015
Thanks HulaHoop! That's very interesting.
Aug 11 2015
- Nymservers do support attachments. Any files attached in a conventional message are converted into base64 encoded text appended to the end of the message body:
Jul 20 2015
Jul 18 2015
Safe defaults are always the smart thing to do, so I agree that the current behavior should be as it is out-of the box, but for more flexibility can you make direct access to the user keyring an option that powerusers can enable? To make sure no mistakes are made, Nymphemeral could show a confirmation prompt warning the user not to use the option unless they know what they're doing.
Upgrading Server Manager to handle this still works, I'm just putting ideas out there :)
Jul 17 2015
Jul 16 2015
I can successfully upgrade nymphemeral with pip however I still have the same error with mix.cfg
Jul 15 2015
It seems that pip has been updated and nymphemeral is not installing as it should. HulaHoop, when you were testing nymphemeral, did you install it with pip or built it from source?
I moved the Message Path into its own section above Instructions to give an overview. Do you think this is the right place?
Jul 14 2015
I haven't tried it before but could this work?
Excellent. It was a better polished version of what I wrote. I replaced everything with your text. Feel free to directly edit the page and I'll accept the changes.
Jul 13 2015
Created new page at https://www.whonix.org/wiki/Nymservers
Ok I'll add the part about sending choices in the introduction, to give the user the whole idea of how it works.
Jul 12 2015
I pushed a major change to the wiki. Many parts are rewritten and new information added.
Jul 11 2015
You know how users will have to renew remailer chain information - usually once a day? this dummy message sending test could be part of that procedure instead of something done on (every) startup by nymphemeral.
Jul 10 2015
So are you just checking for the existence of the file or are you also parsing its contents and going off of that? The first method (if possible to implement) would make it more robust because it makes less assumptions I think.
Jul 4 2015
Got it. Are you still having the same mix.cfg error?
Yes. I've also tried many other likely paths but with no success unfortunately.
I am not sure if I should be posting here. But apparently I am allowed to.
No worries. It's open to public. Anything constructive to this ticket. Your welcome here. Your post looks very constructive.
I assume Whonix already comes with Mixmaster installed, but probably somewhere else.
Yes. Current Whonix stuff, related to mixmaster: