How to..

[chan] bitmessage
Jun 27 06:05

So to allow incomming connections from both clearnet and Tor,this must be in the the torrc config file,and then run tor.exe when its done?: socksproxytype = SOCKS5 onionhostname = abcdefgh.onion onionport = 8444 sockslisten = true 2.) But how do I find the correct onion hostname? Does it generate one automatically? if so... where? 3.) Whats the delay of receiving and sending message to someone who hasn't configured their Bitmessage with Tor Hidden node and the ones who have configured their Bitmessage with Tor hidden node?

[chan] bitmessage
Jun 27 06:53

To get your onion hostname for your Tor hidden service you must: 1. create a directory for the hostname and private key file. 2. add the directory entry to your torrc file 3. shut down and restart Tor. this will automatically generate a hostname file. 4. open the directory you created and you will see a text file with the onion hostname. Don't confuse the onion hostname with the private key. Never share the private key.

[chan] bitmessage
Jun 27 06:58

Can you give me an example how it looks like in the torrc file for the configuration for BitMessage,how it looks like,but without give any more info from it? because from what you explained,I need to also have a line with where the directory for the hostname and private key file is located and I dont see that on the FAQ

[chan] bitmessage
Jun 27 07:55

Here is an example of what needs entered in the torrc file: HiddenServiceDir /home/user/apps/TorBrowser/HiddenServices/PyBitmessage HiddenServicePort 8444 127.0.0.1:8444 The directory path in the first line needs to reflect YOUR directory path. Make sure the HiddenServicesPort matches what's in your keys.dat file.

[chan] bitmessage
Jun 28 01:36

I use a shell script set up an ephemeral hidden service and configure bitmessage before running bitmessage. then when bitmessage exits it removes the hidden service.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 28 04:34

I don't recommend this. If you're not running bitmessage 24/7 it's probably better to not setup a hidden service at all. If you do run it 24/7 but restart often, then it's better to keep the same onion address. Peter Surda Bitmessage core developer

[chan] bitmessage
Jun 28 11:20

Hey nice idea. I've been using a hidden service with a fixed .onion address so far. Care to share your script?

[chan] bitmessage
Jun 28 12:17

Please share the code! Hundreds of people need your solution!

[chan] bitmessage
Jun 28 12:40

The script would be simple to write yourself. Use bash to perform these operations: sudo killall tor rm /..../private_key rm /..../hostname tor sudo killall PyBitmessage (or PID of bitmessage) awk or sed the new onion hostname into keys.dat PyBitmessage done shouldn't be too hard to figure out.

[chan] bitmessage
Jun 28 12:48

Why would you do that, though? It doesn't exactly give you anything, but it fills up the node lists of other people with onion addresses, which will be unreachable, making it bit by bit harder to find a node to connect to.

[chan] bitmessage
Jun 28 13:16

Change the manner in which bitmessage resolves nodes to be more efficient. Distribute php/http bootstrap scripts for free hosting users worldwide. Make bitmessage do pings from bootstrapping nodes to those in the knownnodes list on a separate, dedicated realtime socket on all nodes. The programmers should overcome problems by design rather than by having a manual of arcane rules for users.

[chan] bitmessage
Jun 28 13:18

Except, ANY system works better if the largest number of participating parts is behaving properly. If a large number of parts of any system behaves incorrectly, it's not something a programmer can fix.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 28 16:11

While it is true that the node list management can be improved (and I started doing that with 0.6.2 and still continuing), there is still the question of the benefit of an ephemeral node address. It doesn't improve connectivity, speed, or anonymity. It doesn't really help the network meaningfully unless you run your node 24/7. It may make sense for protocols which require you to accept incoming connections in order to work, but not for Bitmessage. If you want to both help the network and have anonymity, the best choice is to setup a permanent node on a VPS somewhere in the cloud, and independently use tor-outbound-only connectivity on your laptop/desktop. 0.6.3 will have a dramatically lower memory requirements, so you should be able to use a cheap VPS. Peter Surda Bitmessage core developer

[chan] bitmessage
Jun 29 02:34

Reputation systems can reduce this a pretty significantly.

[chan] bitmessage
Jun 29 08:16

Sorry, my solution is highly specific to my system. However the following script illustrates the general idea although I haven't properly tested it even works. It requires python3, stem and Tor 0.2.7.1+. The idea is to run the script with the path to keys.dat as the only argument. It then reads some onion settings, instructs tor to create a hidden service (generating a new private key if necessary and adding appropriate settings to the end of the keys.dat in a duplicate section), then runs bitmessage. When bitmessage ends the script ends and tor automatically discontinues the hidden service. #!/usr/bin/env python3 import argparse import configparser import subprocess from stem.control import Controller parser = argparse.ArgumentParser() parser.add_argument( 'bm_config_file', type=argparse.FileType('r+'), help='location of keys.dat') args = parser.parse_args() config = configparser.ConfigParser(strict=False) config.read_file(args.bm_config_file) local_port = config['bitmessagesettings'].getint('port') hs_ip = config['bitmessagesettings'].get('onionbindip', '127.0.0.1') hs_port = config['bitmessagesettings'].getint('onionport', local_port) key_type = config['bitmessagesettings'].get('onionkeytype', 'NEW') key_content = config['bitmessagesettings'].get('onionkey', 'BEST') discard_key = key_type != 'NEW' with Controller.from_port() as controller: controller.authenticate() response = controller.create_ephemeral_hidden_service( {hs_port, }, key_type=key_type, key_content=key_content, discard_key=discard_key, detached=False, await_publication=False) service_id = response.service_id if not discard_key: s = ''' [bitmessagesettings] onionhostname = {}.onion onionbindip = {} onionport = {} onionkeytype = {} onionkey = {} '''.format(service_id, hs_ip, hs_port, response.private_key_type, response.private_key) args.bm_config_file.write(s) args.bm_config_file.flush() args.bm_config_file.close() subprocess.run('python')

[chan] bitmessage
Jun 29 10:13

you forgot something like this: subprocess.run('tor') subprocess.run('bitmessagemain.py') .......................... subprocess.run('ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9') subprocess.run('ps aux | grep -i TorBrowser | awk '{print $2}' | xargs kill -9')

[chan] bitmessage
Jun 29 10:14

Yes censorship by the majority is good.

[chan] bitmessage
Jun 29 10:17

or subprocess.call() ???

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 29 11:18

I can only repeat what I said, having an ephemeral hidden service bitmessage node provides no benefits to anyone. If for some reason you're unable to run a fixed hidden service address (e.g. you're storing the configuration in volatile memory) and still want to help the network, then fine, but otherwise please don't use it. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 1 00:32

That's not what it even is. Like, at all. The whole idea of one is that people that say useful/interesting/amusing/{insert your choice of adjective here} things are given more attention, while others get less. *Every* group of people has things they don't/can't/won't discuss; that's kind of just how humans work. Oblig xkcd: https://xkcd.com/1357/

[chan] bitmessage
Jul 1 00:54

Forgot to mention: It can also refer to automated systems; nodes are given reputation scores based on uptime, connection consistency, etc. That way malicious ones don't have as much of an impact.

[chan] bitmessage
Jul 1 01:03

Also a service to request ratio can greatly help mitigate malicious clients. It's basically a proof of work without using hashes. A client should only be able to send a fraction of the bandwidth it forwards. Perhaps for every 30 messages forwarded 1 message can be sent.

[chan] bitmessage
Jul 1 08:34

Learn from the events that required implementation changes to original peer based filesharing systems: these came under well funded attack for copyright piracy reasons. Many of those countermeasures are directly relevant to Bitmessage. Put some strategic thinking in that direction and discuss them here ( But please post in a renamed Subject Thread that includes same unique text within open chan message text and post insightful comments with 28days TTL)

[chan] bitmessage
Jul 1 08:50

> post insightful comments with 28days TTL yes. everyone: when you post something important, or send a message direct, always use 28 days TTL: for a couple good reasons. 1. Many ultra paranoid users don't run a permanent node and only connect every few weeks to download messages then go dark again (like me). The only messages we'll get are ones with a long TTL. 2. A large number of users using 28 TTL helps mitigate timing attacks and in private messages preserves the anonymity of sender to receiver, if at least several people do it consistently. This does not mean use 28 days for every message. Just the important ones.

[chan] bitmessage
Jul 1 09:09

Better way is to limit incoming speed. You don't know which messages are forwarded, which created. In Emule we have credits/rewards system stored in remote nodes. It's called DL/UP Modifier. In Emule every big uploader downloads faster. In BM every big uploader should be limitted.

[chan] bitmessage
Jul 1 09:53

connections between nodes need to be encrypted. without this a network survey can determine origin of an object by seeing which node sent it earliest.

[chan] bitmessage
Jul 1 10:00

Well, Peter has been doing quite some great work on this end. Of the 18 connections I have right now, only 4 are without encryption.

[chan] bitmessage
Jul 1 10:03

How to enforce encryption?

[chan] bitmessage
Jul 1 10:04

I don't think there's a way to enforce it. But the current versions of PyBitmessage (0.6.1 and 0.6.2) will always first try to establish encrypted communication first and fallback to legacy if the other side doesn't support it. Peter would have to answer if there's a way to get PyBitmessage to ignore nodes which can't encrypt.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 1 13:11

Since about 0.5.8 (it's in the release notes, I'm too lazy to check), PyBitmessage will indicate via a bitflag that it supports TLS during the BM handshake, and if both sides indicate this, the connection will turn on TLS. This isn't configurable. There is no hard fallback (if both sides indicate TLS support and the TLS handshake fails, the connection will die), only a soft one (if at least one node doesn't indicate TLS support, the connection will continue unencrypted). There are certain restrictions: - incoming connections are only encypted if you have python 2.7.9 or higher. This is due to limits of older python versions (they don't support anonymous TLS server mode). In the future, when authentication is added, I believe this restriction won't apply anymore - if both sides have python >= 2.7.9 and PyBitmessage >= 0.6.2, it uses TLS version 1.2, otherwise 1.0. Again this is due to limitations of older python versions. The platforms that I checked use ephemeral session keys (i.e. the connection has forward secrecy). At some time in the future, once everyone upgrades and other implementations add TLS, TLS will be mandatory and nodes will refuse connections to/form peers that don't support TLS. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 1 14:01

Can anyone tell me how to get exactly the most recent or best bugfixed version of bitmessage? I got 0.6.2. There was a problem with old / expired objects being re-routed by another bad node. I was getting them even after deleting them. I suppose I should NOT have gotten them. Would that indicate that my node is bad, too? help?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 1 14:48

They shouldn't reappear in your inbox, if that's what you mean, that would be very strange. If you're merely getting messages in the log or on the console, you can ignore them, they merely have an informative character and merely sound unnecessarily ominous. If you really want the bleeding edge version, you can get the source from github (v0.6 branch), and for a couple of weeks there have also been daily snapshots for windows, which can be downloaded from https://bitmessage.org/download/snapshots/ Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 2 12:12

what about the implementations in other languages, apart from PyBitmessage? all of those will need to be upgraded too. many seem incomplete still, or still don't support latest protocol. hard to keep current when only up-to-date implementation is PyBitmessage - maybe this should be more coordinated across languages, like picking an 'official' client or at least library for each major language.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:14

I don't think any other implementation supports TLS. I documented the TLS parameters in the wiki a long time ago. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 2 12:22

MiNode does. However, it's not a full client (it can't send messages).

[chan] bitmessage
Jul 2 12:34

For reference: https://bitmessage.org/wiki/Protocol_specification#version >A "verack" packet shall be sent if the version packet was accepted. Once you have sent and received a verack messages with the remote node, send an addr message advertising up to 1000 peers of which you are aware, and one or more inv messages advertising all of the valid objects of which you are aware. >The following services are currently assigned: >Value Name Description >1 NODE_NETWORK This is a normal network node. >2 NODE_SSL This node supports SSL/TLS in the current connect (python < 2.7.9 only supports a SSL client, so in that case it would only have this on when the connection is a client). >3 NODE_POW This node may do PoW on behalf of some its peers (PoW offloading/delegating), but it doesn't have to. Clients may have to meet additional requirements (e.g. TLS authentication) (proposal) https://bitmessage.org/wiki/Protocol_specification#verack >verack >The verack message is sent in reply to version. This message consists of only a message header with the command string "verack". The TCP timeout starts out at 20 seconds; after verack messages are exchanged, the timeout is raised to 10 minutes. >If both sides announce that they support SSL, they MUST perform a SSL handshake immediately after they both send and receive verack. During this SSL handshake, the TCP client acts as a SSL client, and the TCP server acts as a SSL server. The current implementation (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 protocol, and prefers the secp256k1 curve (but other curves may be accepted, depending on the version of python and OpenSSL used). https://bitmessage.org/wiki/Changelog >0.6.0 >QT interface overhaul >Opportunistic TLS support This is every occurrence of the word SSL or TLS on the wiki. Porting this to other langs could require lots of trial and error, and many other language impls seem incomplete or out-of-date as-is. So currently, all users of other languages will be cut off from the network if hard-TLS req goes live. Why even claim support for languages other than Python if the Python client is the only one kept current?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:39

Ah, good to know. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:51

The reason why there isn't more is that the it works the same way as other TLS and relies on OpenSSL to do everything. The actual implementation is literally two lines of code, one calling python's wrap_socket and another one do_handshake methods from python's ssl module. In python 2.7.9 or newer, it also sets up a ssl context variable to explicitly remove certain SSL configuration parameters which aren't needed (it will work without it, it just results in a more strict implementation of the specification). While there is more TLS-related code in PyBitmessage, that's is detecting version of python and OpenSSL, error handling, buffer flushing, asyncore support, loading dummy keys and workarounds for missing library/python functionality. That isn't specific to the Bitmessage wire protocol. Peter Surda Bitmessage core develop

[chan] bitmessage
Jul 2 13:02

Granted, in Python many things are 2 lines of code. And if you only use it to communicate with other Python impls, chances are that they used the same 2 lines of code calling the same exact library and it all just works. But it tends to leave certain details a bit unclear for those who need them for other languages. What is Python's wrap_socket(), in raw OpenSSL calls? What is Python's do_handshake(), in raw OpenSSL calls? What specific SSL config parameters are being explicitly removed in python 2.7.9 or newer? Also all those workarounds that will presumably need to be ported too. This looks likely to be a lot more than 2 lines of code: https://stackoverflow.com/questions/4236526/looking-for-a-high-level-c-ssl-library And a lot of very frustrating debugging and staring at pcap files. I'd be surprised if someone does it.

[chan] bitmessage
Jul 2 13:09

For instance: >The current implementation > (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 > protocol, and prefers the secp256k1 curve (but other curves may be > accepted, depending on the version of python and OpenSSL used). Which other curves may be accepted? Under what exact circumstances? What if you aren't using Python in the first place ("depending on the version of python...")?

[chan] bitmessage
Jul 2 13:12

Or do we just treat the Python impl as the spec, if the spec doesn't contain this information? It is the reference client after all. It's just that trying to get an exact behavior match in another language for the behavior of a specific Python library is often pretty hit-or-miss and can get quite time-consuming. A more language-agnostic unambiguous spec could potentially help reduce the amount of pain involved for anyone trying to keep the other language impls current.

[chan] bitmessage
Jul 2 13:46

This is indeed very convenient: http://www.programcreek.com/python/example/1124/ssl.wrap_socket Here's the approximate equivalent in OpenSSL: https://stackoverflow.com/questions/7698488/turn-a-simple-socket-into-an-ssl-socket Note all the discussion about needing certificates -- do we need those here? I don't see anything about certificates in the docs or this thread. Also comments stating that using the library is notoriously difficult and error-prone. As an early-stage end-user of the protocol, it seems like entire languages are going to be dropped from usability if someone doesn't hack their way through this. This makes it difficult to justify building something based on anything but the Python XML-RPC API.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 16:42

> Granted, in Python many things are 2 lines of code. And if you only > use it to communicate with other Python impls, chances are that they > used the same 2 lines of code calling the same exact library and it > all just works. But it tends to leave certain details a bit unclear > for those who need them for other languages. Then that's a python issue and not a BM issue. > What is Python's wrap_socket(), in raw OpenSSL calls? > What is Python's do_handshake(), in raw OpenSSL calls? I don't know. > What specific SSL config parameters are being explicitly removed in > python 2.7.9 or newer? It restricts which elliptic curves can be used. I'd like an crypto expert to look at the choice of curves and give feedback. > Also all those workarounds that will presumably need to be ported > too. The workarounds make TLS behave according to OpenSSL documentation rather what python's developers thought ssl should behave like. When I was writing it originally, I tried the connectivity with openssl s_client/s_server (after disabling the BM handshake) and it works, so there isn't anything hidden going on, apart from my own bugs, which I hope are fixed in 0.6.2 and in asyncore. > This looks likely to be a lot more than 2 lines of code: > https://stackoverflow.com/questions/4236526/looking-for-a-high-level-c-ssl-library > And a lot of very frustrating debugging and staring at pcap files. > I'd be surprised if someone does it. I also used wireshark when implementing debugging. The problems occured due to undocumented python bugs and me not doing buffer flushing correctly. Oh and when using OpenSSL 1.1, you have to add "@SECLEVEL=0" to anonymous ciphers. After I fixed/worked around that, it worked fine. None of this is BM specific. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 16:59

> For instance: > >The current implementation > > (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 > > protocol, and prefers the secp256k1 curve (but other curves may be > > accepted, depending on the version of python and OpenSSL used). > > Which other curves may be accepted? Under what exact circumstances? Any curve under any circumstances. I'd like to harden this, but I'm not a crypto expert and didn't want to unnecessarily break stuff. So if you can't use the secp256k1 curve, you still may get lucky as some nodes may accept other curves. In retrospect I'm not overly happy over the choice of curves and would like a cryptographer's opinion about adding others (OpenSSL allows to specify more than one in the order of desired priority). > What if you aren't using Python in the first place ("depending on > the version of python...")? If both sides accept curves other than secp256k1, they can agree on a different one. If you have python < 2.7.9 and are using it's ssl module, it doesn't allow to specify which elliptic curves to announce, so the negotiated curve is undefined. Recent pyopenssl packages don't have this restriction and can be used instead, however I haven't added this code because on my test environment at that time, Ubuntu 14.04, the distro contained both the old python version and old pyopenssl, so you'd have to install at least one of them manually anyway and I think in that case it's easier just to use venv to setup a newer python version. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 17:10

> Note all the discussion about needing certificates -- do we need > those here? I don't see anything about certificates in the docs or > this thread. Currently the protocol specification doesn't support certificates (the only specified cipher is anonymous, i.e. certificate-less). The PyBitmessage repository contains dummy certificates to work around python's bugs, which however have no cryptographic relevance. I want to add certificates later, the nodes will include their certificates when they announce themselves and then the client can use that information to verify it. If it doesn't want to verify it, or if the server doesn't have a certificate and the client doesn't mind, it will continue unauthenticated as it is now. > Also comments stating that using the library is > notoriously difficult and error-prone. That's probably why python has wrap_socket. > As an early-stage end-user of the protocol, it seems like entire > languages are going to be dropped from usability if someone doesn't > hack their way through this. This makes it difficult to justify > building something based on anything but the Python XML-RPC API. As I said before, almost all my time when debugging turned out to be caused by bugs in python, hidden openssl things (like how anonymous ciphers work with 1.1) and my own bugs. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 3 03:55

This and the preceding replies were quite informative. Thank you very much for elaborating. I have a better understanding of what would be needed to try implementing this extension of the protocol in C/C++ now. Do you have an opinion of which C/C++ bitmessage library is the most complete and up-to-date? BitMRC looks like it but not sure.

[chan] bitmessage
Jul 3 13:55

> And a lot of very frustrating debugging and staring at pcap files. > I'd be surprised if someone does it. Busy FinTech Specialist Programmers, well paid. Looking myself at Python raw sockets programming ( Network Focussed Pentesting courses / Vids ) Been there in C decades ago; maybe better placed at that level and build custom python abstraction programming layers to a common testing standard if you really must code real time critical stuff in hiher level abstractions. Dont forget that the multithreading capability in python is deliberately limited, and that Py2 + Py3 implementations differ. So you have the dubious pleasure of doing it over again, later.

[chan] bitmessage
Jul 4 22:19

oops, yeah I meant subprocess.call(). One can use os.system() or popen, which is deprecated but works in older py. Also, if using shell commands in a py script, shell returns output to the script that needs to be checked to preven errors. In this case use: subprocess.check_output("ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9", shell=True).strip() I set it up as a bash alias so If I need to kill bitmessage I just hotkey the shell and enter it: alias killbitmsg="ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9"

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 6 18:01

For the first time I now noticed in the network status that indeed MiNode 0.2.2 negotiates TLSv1.2. Well done! Peter Surda Bitmessage core developer

[chan] bitmessage
Sep 24 16:40

refresh lawl

[chan] bitmessage
Sep 24 16:43

my point being : it is September now , and this post is from June ! nice caching job there ! use google for this malfeasance ;-)

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
BitMessage crash Nov 18 14:28 2
Tor replacement Nov 18 13:10 4
Alternative Bitmessage port for official assignment with IANA? Nov 18 02:20 1
codewordtest2 Nov 17 21:52 1
bitmessage history Nov 15 08:43 28
stream and pool diagram Nov 12 12:05 21
( ͠° ͟ ʖ ͡°) Nov 10 09:51 2
I'm back. Nov 9 17:55 1
streams and pools Nov 7 01:37 1
How to examine bitmessage objects Nov 7 00:45 5
Tor curve vs bm curve Nov 7 00:45 4
keys.dat values Nov 6 23:16 2
Bitmessage history Nov 6 08:08 9
Pseudo-mailinglist vs chans? Nov 5 21:47 2
bitmessage node rating? Nov 5 21:32 2
can I connect to both onions and standard? Nov 5 19:33 11
Bitmessage won't exit cleanly Nov 4 18:06 2
keys.dat must be encrypted Nov 4 12:09 12
Question Nov 3 20:09 5
It's actually not that hard to de-anonymize someone on bitmessage. Nov 3 19:49 8
It's actually not that hard to de-anonymize someone on Nov 2 14:18 1
Bitmessage snapshots Nov 2 13:14 3
Why chan address? Nov 1 06:26 2
HASH Q Oct 31 21:16 1
bitpetite scam Oct 31 08:34 2
GitHub Supports Islamic Clitoris Removal Oct 31 01:02 14
What exactly is the address of [chan] general? Oct 30 05:29 7
MiNode addr bug Oct 27 11:53 1
Hi, users ! Oct 27 07:18 5
No incoming connections now Oct 26 09:40 33
RE: bitmessage implementation in any other programming language Oct 23 17:01 1
disabled address still working Oct 23 12:47 8
apinotifypath Oct 22 01:11 1
checkdeps.py error Oct 21 22:04 3