Feb 13 08:05
wtf is that?
Feb 13 11:06
> wtf is that? No idea.
Feb 13 15:30
> wtf is that? There is an attack at the moment exploiting a bug in the extended encoding. If you are using PyBitmessage 0.6.2 or later, please shutdown and wait until you see a commit in the repo that fixes it, or until 0.6.3 is released. This is not a drill, the exploit can have serious consequences. Peter Surda Bitmessage core developer
Feb 13 15:44
Can you sign your message with your GPG key? Can you announce it in the webiste, in its forum, in Reddit, in Github...?
Feb 13 15:47
I'll probably emergency-release 0.6.3 even though it isn't finished and I don't have a fully working OSX build environment. The latest commit should close the attack vector but I'm still testing. All of my commits are GPG signed. I really recommend to immediatelly shutdown PyBitmessage and update, if you're running 0.6.2 or later. Peter Surda Bitmessage core developer
Feb 13 16:54
Could you provide more details? I would like to know what parts of my system were compromised so I know what measures to take.
[chan] bitmessage <<Ext>>
Feb 13 17:01
https://github.com/Bitmessage/PyBitmessage/commit/3a8016d31f517775d226aa8b902480f4a3a148a9 Someone posted earlier asking about injection attacks, which was poo-pooed. Then we see hole discovered for injection attack.
[chan] bitmessage <<Ext>>
Feb 13 17:04
let me guess ... the "bug" allowed the attacker to snarf everybody's private address keys?
Feb 13 17:04
The exploits that I saw were twofold. One used windows and downloaded some binary. Virustotal does not list the binary as malware. The binary doesn't look like a windows executable so I'm not sure what it is. I'm not sure it actually ran the binary. The other exploit attempted to send electrum wallets on Unix-like systems somewhere on the internet (presumably to the attacker) and open a remote shell. There were others which just caused a crash. The crash would have prevented the subsequent exploits from working until you restart PyBitmessage. Peter Surda Bitmessage core developer
Feb 13 17:34
Oto jak "bezpieczny" jest bitmessage - dziurę wielką jak Atlantyk w BM opisuje sam developer programu. Czekam na wyzywanie mnie od trolli i dezinformatorów.
Feb 13 17:34
Any possibility that an attacker was able to vacuum up keys.dat data?
Feb 13 17:37
> Any possibility that an attacker was able to vacuum up keys.dat > data? Yes it's possible. Peter Surda Bitmessage core developer
Feb 13 17:39
Does anybody know which lines in the codebase were being exploited? I'd like to have a look at it.
[chan] bitmessage <<Ext>>
Feb 13 18:10
Hello, Do you think that those exploits concern only windows OS, or other OSs may also be concerned ? Thanks Harry
Feb 13 18:33
> Hello, > Do you think that those exploits concern only windows OS, or other > OSs may also be concerned ? I saw exploits for Windows and Unix-like systems. Peter Surda Bitmessage core developer
Feb 14 04:54
Feb 14 09:25
BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw didn't broadcast ):
Feb 14 09:43
> BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw didn't broadcast ): Well I did get it ... Peter Surda Bitmessage core developer
Feb 19 22:06
I have a system designed specifically to defeat attempts at exploiting a running python daemon ( no GUI ) - custom shell with framework that can also be used for active response if the circumstances merit it. It didn't : I caught the tail end of vulnerability attempts in a quick sync yesterday from a very high bandwidth connection. Using older, inefficient networking code versions deliberately; by the time the processing had gotten around to hitting maliciously malformed stuff reporting the exceptions ValueError and TypeError I had switched to a different low bandwidth network setup for close forensics. The only affected system(s) were gathering 600+ open chan posts. All other systems that Blacklisted them ans had only private key pairs were entirely unaffected in the same timeframe The only GUI based PyBM running systems had minimal open chan exposure. No incidents that led to ValueERROR or TypeERROR seen. No privilege escalations or anything effective happened. ( All non windows systems ) DEBUG logging in effect. But what I'd REALLY like is additional DEBUG level code to catch the bad stuff as it is hauled up for processing to crash and burn : being able to save the malformed content as (say) hex for proper analysis before, after, timestamped. Handicapped by lousy python skills; I'd appreciate some community effort here to achieve this goal, pool a decent analysis archive that is statistically significant. Busy too with other things, but if the content can be stored in some universal format that does not need funky PyBitmessage codebase knowledge to do format conversion I can aim it at folks that would be willing to spend time reverse engineering an archive of it. If you guys are not already on it! Any correlations with the earlier heist of digital currencies from a dedicated hacking team would provide useful intelligence for LE. Is it possible to retrieve anything useful just AFTER the event(s) from messages.dat? Some pointers would be appreciated.
Feb 19 22:16
> Handicapped by lousy python skills switch to Pascal. Python syntax is largely from Modula, which is from Pascal. You should be up and running in a day and your compiled code about 20-100x faster than Python.
Feb 19 22:31
I do appreciate the differences, but not convinced about the magnitude of speedup ( cpython built, optimized - has compared favourably to some crypto code utility executables written for the same purposes in native C. Turbo Pascal was a speciality that provided some lavishly funded and very interesting contracts; when Borland were at their peak and you could find the main Devs in London. Math Modelling tools were pretty damn good, and (almost) Black Boxes you didnt worry about in depth understanding of internal code function and scoping issues in very large re-usable component big team projects. But I moved to ANSI C/C++ when the genius Walter Bright came out with the first native ix86 compiler VERY early in the AT&T streams evolution. You had to work really hard to build executables that were crippled with memory leaks and fragmentation showstoppers after long runs. Not Tried Free Pascal - but did look at it a little bit. Not enough to be dangerous though. Is that what you are using?
Feb 19 22:51
This dadadodo drives my inner grammar nazi mad. The code in 0.6.3 would print the exploit string into logs with "error" severity. Which the default log setup would catch. Later I added a filter so it's not in 0.6.3.2 anymore. However, I did subsequently more hardening in the v0.6 branch to get rid of potential alternative attack vectors. So if you're confident you can handle it, you can go to messagetypes/__init__.py and remove the whitelist check (first three lines in constructObj), then it will print the exploit code into logs again. It now won't allow loading any code from outside the messagetypes directory, and the code has to be loaded on PyBitmessage startup, so it's got more protections. I'm keeping the whitelist for the time being until the code is reviewed by someone else. I did make a backup of messages.dat from the time of the attack for later analysis, although at the moment I don't have the tools to easily decrypt individual objects, I'd have to write them. Peter Surda Bitmessage core developer
Feb 19 23:14
LoL : ANY person that has mastered a First Language capable of turning complete sentences into single words deserves serious respect. Minimal grammar, maximal compression. Frightening levels of efficiency and productivity. As does your close attention to solving the vulnerabilities; rapid mitigations and quick moves on to fixes seen in one pair of commits. Better than many a highly paid team with an equally complex codebase to deal with Adobe <*cough*> My Appreciation added the many votes of thanks. You EXPLAINED enough core issues for me to be able to do something useful in a programming language that I never did "get into". Like apply many patches to Non Asyncore snapshots also in less than a few hours - a year older than the current 0.6 / 0.6.3 master syncs. For reasons I cannot go into on a public chan : it is imperative that the "first connect" time for the asyncore based version be able to sneak in under a strict time limit where tor de-anonymization is statistically very likely. Until that time ( no pressure! ) I've got to live with trying to keep a non asyncore daemon deployed "fork" alive ans useful with exponentially increasing numbers of critical patches. You'll get there! ( And Thanks in Advance for that milestone ) [ Snipped earlier content ]
Feb 20 00:05
> but not convinced about the magnitude of speedup Pascal compiler is the fastest and best optimizing compiler on the market. Cython comes nowhere close. Any sizeable Cython program can take a very long time to compile. A second or two in Pascal. Pascal code is optimized machine code. Cython has to run through the Cython parsing and a C compiler. The errors I constantly encounter with Cython don't happen in Pascal. I prefer Nuitka to Cython, but even that is slow and cannot produce the speed of binaries from a Pascal compiler. > Not Tried Free Pascal - but did look at it a little bit. Not enough to be dangerous though. Is that what you are using? I've programmed in Python, FreePascal, OmniPascal, Lazarus, Visual Studio Code (supports Pascal), ECMAScript (no jquery for me), PHP, Tk, HTML, CSS, Bash. I avoid C like the plague. I can make sense out of C code but I would be hard pressed to use it. It is a systems language. C was designed for operating system code and simple utilities--which is why Torvalds still uses it. But for highly complex interface applications C is a nightmare to maintain. Pascal code is easier to maintain. It has enforced structure--not like Python's indents--but rather in the order of elements in each module or procedure, that makes the code readable. Everything you ever heard about ancient Pascal has no bearing on modern Pascal. Some nitwit with a wad in his panties keeps talking about a version of pascal from 30 years ago, and people think that applies to modern pascal. It's like complaining about Python 1.3 when we're using 3.5. Modern Pascal's compiler is far superior to all C compilers on the market. All of them. A large Pascal codebase will usually compile to optimized machine code in a second or two. It compiles significantly faster than Golang. I created my own text editor in Pascal and it starts up faster than any C-based text editor I've ever used, which is dozens of them. This is without managing memory but letting the compiler choose. It would be faster if I got in there and did a bunch of pointer code. Many companies still use Pascal for engineering and industrial automation. They don't waste their time promoting the language because they are making money instead of trolling the crypto-anarchist and coder beatnik scene in silly con valley. Pascal is ignored because of politics and uniformed prejudice created by competitors. Languages are generally not chosen for their quality but rather due to all kinds of politics, advertising, spin, and market factors. This is why Pascal has such a small market share--Wirth refused to promote his product the way some companies and groups promote theirs. Python has the potential to eventually outstrip both C and Java in its popularity, and when you look at the structure of Python code compare it to Pascal code and see the similarities. I doubt Pascal will ever become as popular again as Python or Java, but I have no doubt some of the fastest and most useful software written in corporate environments is 100% Pascal code.
Feb 20 00:51
Looking good and shaping up. More padlocks, hombre. Even more.
Feb 20 12:23
Someone should port BM to FreePascal and make BM great again (without backdo^H^H^H^H^H^H vulnerabilities placed in code by some noname programmers.
Feb 20 12:33
Noname programmer here, you have my permission to go fu^H^H^H^H^Hproceed.
Feb 20 12:48
How often you intend to try again to convince people that anyone still gives a fuck about Pascal?
Feb 20 12:50
Stand back from the detail a little, and lets examjne Woods from altitude and below the compost layer, upwards. The principles of breaking into ANYTHING : Get at the lowest layers that have been neglected or misunderstood. Python as an application layer provides a comprehensive attack surface to undermine. By its very nature. For similar reasons that PHP remains a lousy security choice in webserver cgi coding ( using old school terminology ). Compiled python application code equally so if the Rapid Application developer is too busy to deal with all of the nuances in abstractions that make the language so productive : for Proof of Concept (white paper) And when they burn time and achieve THAT expertise - no longer valid as underlying implementations are patched by hundreds of contributors in a collaborative project - there are the "libraries" to consider. Unless you deep dive all of them to seek out the grey areas it cannot possibly be considered as secure by design. ( The implementation; I assume here that the SPECIFICATION has NO holes in it to attack if coded perfectly, or imperfectly ). RAD Python is a great tool for pen testers to evolve attacks against slowly adapting targets. ( Just a skim read of TJ's book will enlighten ) There are a couple of other Network security topic books for Python that are an essential reference. It is probably not the best language for a *defender* to write in. Isolate the *sections* of the application that are peripheral to the networking and untrusted external data processing core most at risk. That CAN be done by (re)design in the same application language Class structure, even if it is painful to change Class hierachies etc etc. One of the reasons I abandoned Python is because the RAD GUI libraries were never worked-on sufficiently to make a transition to Python3 viable. Staying over-long with dangerous legacy processing aspects (UTF for one) is more likely, and no matter how mature the codebase becomes, its still lipstick on a pig ( as far as a coding for a security focus is concerned ) Anyone that has burned days of their life writing a great GUI would be naturally disinclined to redo that work, or burn useful resources by delegating it to capable people more usefully employed on higher priority matters. Presentation and easy access to change bitmessage specific functionality is an essential part of the marketing phase to gain a critical mass of investors ( money, dev time, and other resources ). Peter Surda is one that stood up to the challenge taking on a neglected codebase and doing his very best to make it more attractive. Beyond a mere proof of concept to a viable product ( today's lousy priorities that apply to ALL but a few tiny niche markets in software laden products set the initial standard. Code fast ans break things, fix 'em later ). NOT a criticism aimed at any person swept up within this economic model of coding expediency! It cannot stay that way ( a product that is BOTH hardware + software layer SAFE by design such as StMan proposes ): MUST follow crafted rules built from first security design principles. Lets look to the future. Make the communications model scale sufficiently for likely future security focussed communications networks. We seen to have a couple of thousand messages passed daily. What about 2 -3 orders of magnitude higher? Is that feasible with current commodity personal compting platforms? The python demonstrator as is still has a way to go as a mature product, but its come a LONG way from a cobbled together RAD presentation of the 2014 Whitepaper core concepts ( in 3+ years ). As a first implementation. What would the Military do if this was controlling a worldwide comms network ( such as Strategic Air Command used to use during the hottest times in the Cold War Mutually Assured Destruction years? Given the tech as it stands right now - or even Pascal / Ada - as it was 10 -15 years ago ( the typical tech maturity trust of most Military implementations) BUT - with what we know operationally about adversaries NOW... Thinking caps ON folks. For presentations likely to engage the finest minds in academia that have the power to assign PhD student resources towards INTERESTING implementation problems! I'll offer my own support in such endeavours for the project when this emerges. ------------------------------------------------------------------
Feb 20 13:09
All advocates have some content worth consideration, if they have studied something in great depth rather than repeating someone elses belief system I keep an open mind despite my antiquated position. A contemporary of Bill Gates futzing around with Dec 10 mainframes at College. Unlike Mr Gates I didnt have a rich daddy to smooth ruffled feathers when I demonstrated how to log in to any administrator account - from a hollerith card reader ( look it up if you are too young for that ) Pythons space sensitive formatting made me reach into into dusty archives for Hollerith card Fortran programming sheets to pencil in my first Python code, when I learned about it. "Surely NOT!" I breathed. "Dinosaur Do-Do s" was my own first reaction - same as RMS. Keeping an open mind, but not so open as to parrot belief systems, is the most important practice to observe, grasshopper. I recoded a failing PhD Pascal project in Fortran to make it possible for the poor bastard who got persuaded to use such a "Wirthless" language for his project in the 70s. Wrong time, wrong place, wrong language for the implementation was all. Became an advocate for Pascal when Borland first made it so damn good. The earliest "Bolt on" Class based stuff also was ...interesting... But ahead of its time. A little too far, possibly. Then moved on to ANSI type safe languages that STILL had security holes because the SPECS had "holes" or inconsistencies in them... ( Just like the recent WiFi IEEE spec disaster that led to exploits ) ironic that the open source coders that showed great diligence in coding to the specs to the best of their fone abilities generated the explotable programs. The Microsoft and Apple coders that always tread their own corporate path were the ones that had safe product. Funny Old World, aint it!
Feb 20 18:01
> Python as an application layer provides a comprehensive attack surface to undermine. By its very nature. If you follow the Unix way and make every data a string or file and pass every data through a filter as string and pass all function output through filter as a string, there remains ZERO attack surface. If you have cop functions in and out and in between that enforce stringiness without evaluation then their is no penetration.
Feb 20 18:01
> there are the "libraries" to consider. Third party libraries should never be used in security vector code. Rule of thumb is roll your own.
Feb 20 18:03
> That CAN be done by (re)design in the same application language Class structure, even if it is painful to change Class hierachies etc etc. In security domain software there should be no classes. Since classes maintain internal state there is attack surface. It should be functional programming (which Python easily allows) with no classes or internal state. Functional formatted code is easier to read, easier to maintain, and a magnitude easier to debug.
Feb 20 18:04
Roll my own OpenSSL? Alrighty then
Feb 20 18:05
> What would the Military do if this was controlling a worldwide comms network ( such as Strategic Air Command used to use during the hottest times in the Cold War Mutually Assured Destruction years? They would likely code it either in Ada or Pascal, and they would have a custom device built to separate keys and messages from the rest of the system onto a yubikey-like device.
Feb 20 18:06
> engage the finest minds in academia There are no fine minds in academia. Being in academia is proof that one is a sellout who goes along with the herd.
Feb 20 18:07
Hah, pascal, that's a laugh, especially when you already named an alternative which is superior to it in every way.
Feb 20 18:22
it's a shame that smalltalk does not compile to native code.
Feb 20 18:40
Ada is based on Pascal, genius.
Feb 20 18:43
I was well aware. It's still not much like Pascal, but exceeds it in every way, so why even name the base when it's crap?
Feb 20 18:54
> Roll my own OpenSSL? Alrighty then Yes, roll your own crypto. I've rolled my own. I've invented my own and it is probably secure. None of the crypto in OpenSSL has any provabe security--it's all assumed with no mathematical proof ever found for those algorithms. With all the vulnerabilities of OpenSSL, yes, roll your own. That's exactly what BSD did. They call it LibreSSL. Elgamal is a good choice for encryption and signing and is very easy to implement. The idea behind curves is neat but all ECC encryption boils down to is Elgamal over curve points. A 6000-bit Elgamal key should provide security for the next 100,000+ years.
Feb 20 18:59
> That's exactly what BSD did. They call it LibreSSL. Forking is now considered "rolling your own"?
Feb 20 19:23
Feb 22 14:29
Sadly, there will be good code contributors and maintainers that WILL f**k up bigtime without the decades of necessary peer reviewed and shared experience as cryptanalysts and algorithm / specification Breakers. Debian screwup causing immense reputation damage and sensitive data loss from affected ssl CAs as one tiny example. You were being sarcastic and not serious I hope! Finessing that comment: ALWAYS deploy a RANGE of options ( different codebases and trusted implementations competing in the same product / algorithm space ) Its monocultures that are REALLY dangerous. For whatever reason: laziness, economics or infiltration by Big Corps with "letters of Marque" ans "Get out of jail free" cards issued by Intel Agencies under Gagging orders.
Feb 22 14:43
This is all a bunch of bull routinely regurgitated by people who've never studied or written their own crypto algorithms. Every one calling himself a programmer should be creating and improving his own cryptography through the course of his career. Many hackers create their own hash and crypto functions. They just don't open source most of them. Why would they since you wouldn't use it anyway?
Feb 22 14:43
Yes Thank you for that essential clarification. The methodology used, if created solely for code reuse and more rapid development / reuse is of importance. I was referring specifically to improving the function of the existing code as a demonstrator, but not a final "secure by design" product. PseudoCode value only. It all has to be (re)done properly, which also introduces other bugs and inconsistencies as the toolchain builds to "Low level virtual machine" architecture level - then the eventual real world silicon architecture. Whcih may ( or course ) also be "programmable" in ways not originally intended or contemplated. All human languages have ambiguities and commit errors of omission as much as commission. Evolution of speech as a social means to lie and misrepresent may defeat the best intentions of a writer ans should always be peer reviewed, as here. Computer languages should be more precise. But they are not perfect.
Feb 22 14:48
WRONG :: except for one very specific case. A small trivially simple mapping of simple characters : Yes. No "control" or formatting "functional" changing types permitted. The Specification for UTF has evolved to such an enormous MESS that it is impossible to use a mathematical proof that the processing algorithm and code you use is unconditionally safe. Process UTF, the safety argument dies. Period. Its unprovable.
Feb 22 14:52
The "Roll my own OpenSSL? Alrighty then" was meant as extremely sarcastic. I mean, "Rule of thumb is roll your own." must be the most idiotic thing I've ever heard. Suggesting that everyone reinvents the wheel every time they do something? Suggesting that every developer is even CAPABLE (interlectually and time-wise) to re-write a crypto-library? Suggesting that it's a good idea to ditch, as you said, decades worth of refinement, peer review and bug-fixing (which will happen inevitably when you write something as complex as proper crypto)? That suggestion must be either severely delusional or trolling. Neither is worth any recognition.
Feb 22 14:54
This is a bunch of bull routinely regurgitated by people who've likely studied crypto algorithms with malicious intent. Such people would have enough reason to try and trick others into trying their hand on crypto, which they will inevitably fuck up on some minor detail.
Feb 22 15:09
Even a troll attempt ( if it was intended as such ) contributed to this quality debate. We are dealing with testing abstract concepts in a trusted scientific falsification basis. That does not guarantee instant perfection in the model / process. But it ensures convergence towards something with a minimum of flaws and early isolation of very human "beliefs" that cannot be clearly justified and tested, even if they seem instinctively correct to the person commenting. It carried precedent value. Win or Lose. A quality discussion not mired in personal attack and vitriol. What we are discussing is just too important for that, otherwise our time here and related development work based upon it is largely wasted. Anonymous posting / Free Speech example. Bitmessage Open Chans CAN work. As good as many crypto/hash standard debates I've attended at OxBridge seminars. Thanks, to eveyone. It will be on Beamstat and available for more than just a few Bitmessage node retention days.
Feb 22 15:18
> As good as many crypto/hash standard debates I've attended at OxBridge seminars. The vital difference here is that these debates would be events where people are physically present. Which means, if one person keeps interrupting, spouting gibberish, trying to rally people against each other, or generally talking shit, they can also be identified and physically removed before they can cause more harm. Which is also the main disadvantage with fully anonymous communication channels. Unable to censor any specific individual is really a slippery slope. It's bad if people that have actually useful stuff to say were censored. But it's also bad that people who only derive pleasure from upsetting other people CAN'T be censored.
Feb 22 15:20
> Process UTF, the safety argument dies. Python 3 compartmentalizes UTF. I believe that would make it type safe.
Feb 22 15:27
> This is a bunch of bull routinely regurgitated by people who've likely studied crypto algorithms with malicious intent. This is a bunch of bull routinely regurgitated by enemies of the Church who think that parishoners can read and understand the scriptures for themselves. Their malicious intent is to pervert the word of God by telling people they can understand it. But that's why we have priests to interpret the crypto, er, eh, the scripture, for those of inferior understanding. > Such people would have enough reason to try and trick others into trying their hand on crypto Such people would have reason enough to try and trick others into trying their hand on personal bible study, which will only cause confusion and chaos and has dire consequences.
Feb 22 15:28
internet => socket => filterfunc => crypto => filterfunc => encoder => filterfunc => scanner => filterfunc => QT/database/etc. No object, value, or file should be passed from one program component to another. It should only be passed to a filter function that is hooked by all other functions to guarantee its activation. Everything is sandboxed by design so that movement of bits and bytes occurs only via filters. The idea of code reuse and rapid development is bottom rung in mission critical / high security domains. Everything is custom and streamlined to the mission, and all fat is cut (re-usable libraries not controlled by the project). Since most of the functions in openssl are not used by Bitmessage most of those functions should be disabled or removed from the codebase, and a custom package shipped. Same for asyncore, dandelion, queues, configparser, random, urllib, hashlib, etc. The functions not needed should be gutted. That way when someone finds an exploit to inject a value somewhere, there's nowhere for the exploit to hook to or call a library function to turn into an exploit. The problem is funding. Who is going to fund such an endeavor? The workload to gut all the libraries would be severe. Exception: libraries developed by other mission critical teams, under the same command, who will be held accountable for their code. Even then in some domains complete compartmentalization is required.
Feb 22 15:35
I see what you tried there.
Feb 22 15:53
> Unable to censor any specific individual is really a slippery slope. If I demanded we censor the pedophiles you might argue the opposite and claim censoring pedophiles would be the slippery slope that leads to censoring grandma.
|Anonymity improvement idea for Bitmessage||Feb 25 05:24||3|
|interface improvement||Feb 25 02:05||1|
|How to start an argument in geekspace||Feb 25 00:26||42|
|Abit 1.0-rc1||Feb 24 18:18||2|
|http://33xtkivab2nthghe.onion/7uim34gdxs5z6b5l72nbji7ste||Feb 24 08:36||1|
|Bitmessage security suggestion||Feb 24 04:01||27|
|Fixes #1131 -- typo corrected||Feb 23 22:19||1|
|little fish||Feb 23 20:07||1|
|test||Feb 23 17:43||3|
|Fixes #1134||Feb 23 14:42||2|
|Fixes #1131||Feb 23 11:37||1|
|Bitmessage feature request for API commands||Feb 23 01:19||10|
|bitmessage launches cmd and then powershell||Feb 22 15:53||56|
|bitmessage tor service||Feb 22 13:31||6|
|I want the FEDS on this chan to know I identified one of their new tactics.||Feb 20 12:03||2|
|Mitigating exploited software with firejail||Feb 19 22:42||8|
|Critical vulnerability in v0.6.2||Feb 19 16:51||50|
|message database seems to be corrupted after all that upgraes and attacks||Feb 19 14:55||7|
|Since upgrading yesterday to 6.3.2, Bitmessage is not connecting||Feb 19 11:12||7|
|Inflood of old messages||Feb 18 19:16||23|
|It is slow making connection.||Feb 18 18:04||1|
|Globewashing||Feb 18 17:44||1|
|how to make bitmessage secure||Feb 18 05:02||1|
|Are you blacklisted/whitelisted?||Feb 18 04:19||2|
|Are Linux systems vulnerable to recent attack?||Feb 18 02:19||12|
|Are you blacklisted?||Feb 18 02:09||1|
|address on Peter's reddit account||Feb 17 23:51||3|
|Can't add entries to black list using Add Entry button||Feb 17 15:20||4|
|Errors while trying to run 0.6.2 or 0.6.1||Feb 17 15:20||4|
|Bitmessage project looking for auditors and/or security specialists (reddit crosspost)||Feb 17 13:21||6|
|HIRE A HACKER/CHANGE GRADES||Feb 17 08:59||2|
|Download it.||Feb 17 07:59||2|
|passphrase strength ?||Feb 16 20:34||8|
|$ cd PyBitmessage ; git log | grep Author | sort -u | blacklist||Feb 16 15:54||18|
|diagram||Feb 16 01:46||1|
|Bitmessage components security seclusion example||Feb 16 01:24||1|
|⩩ 𐄉 ㎮ ䷦ 🞳 🆁 ㍝ f 𝙲 🄦 ➇ ⨘ ㊳ 𝐗 ⦱ 🄹 𝟒 ䷄ Ｋ 🆙 ䷤ 𝐙 ⒄ ₹ ꠲ ||Feb 16 00:04||1|
|NOTICE: Address Revocation||Feb 15 18:28||12|
|Cannot connect since yesterday||Feb 15 17:59||2|
|Questions regarding recent bitmessage data exploit||Feb 15 03:46||2|
|Latest commit borked||Feb 14 05:26||5|
|BM-onion||Feb 14 05:22||5|
|That's my new address||Feb 14 03:40||1|
|BM massacre!||Feb 13 21:23||2|
|Namecoin integration||Feb 13 20:18||11|
|Hashwalling Functions for Security||Feb 13 17:58||2|
|Same old problem connecting to network||Feb 13 17:12||4|
|Injection attack mitigation||Feb 13 16:52||7|
|This denial of service shit needs to be patched||Feb 13 12:00||7|
|Test||Feb 13 11:37||1|
|Proving that BM was sent?||Feb 13 11:07||10|
|bitmessage ...||Feb 13 08:13||1|
|Improve icon for chan + messages: important or not||Feb 13 05:25||2|
|pickle puzzle||Feb 13 01:03||20|
|so happy||Feb 12 16:32||2|
|Fwd: Re: Did everyone else's BM starting freezing up||Feb 11 03:54||10|
|hacker service||Feb 10 03:48||2|
|another feature request||Feb 10 01:12||1|
|bitmessage feature request||Feb 10 01:10||1|
|feature request||Feb 10 01:04||1|
|Questions for the Bitmessage Community||Feb 9 21:30||7|
|Did everyone else's BM starting freezing up||Feb 9 03:21||4|
|A light weight version of the denial of service message||Feb 8 13:22||3|
|RE: Hello.||Feb 8 11:48||1|
|WWtest||Feb 8 10:44||1|
|test1||Feb 8 10:37||1|
|WARNING! denial of service message||Feb 8 10:19||3|
|extended encoding||Feb 8 01:24||7|
|bountyfy -- 7 € payout||Feb 5 20:59||2|
|clean up pyBM github landing page, please||Feb 4 23:00||2|
|Running BM daemon as a service||Feb 4 13:47||6|
|hidden service - long names||Feb 4 12:37||7|
|RAM consumption - RAM not released||Feb 3 21:05||4|
|Bug? First connection quickly breaks||Feb 3 11:41||6|
|Request: debug.log initialization / termination||Feb 2 18:30||2|
|kqueue poller in asyncore bounty -- no payout||Feb 2 14:23||5|
|Bitmessage bug in Help > About||Feb 2 13:59||7|
|Message size is metadata||Feb 2 13:25||6|
|New warning "sni-qt/5864" WARN||Feb 2 12:12||2|
|ordering||Feb 1 10:38||12|
|RAM consumption||Feb 1 10:14||5|
|discrepancy in transmit/receive byte counts||Feb 1 07:53||6|
|BM CPU time||Feb 1 02:39||5|
|kqueue poller in asyncore bounty||Feb 1 00:13||15|
|new theme for beamstat||Jan 31 11:35||2|
|Support request -- dontconnect in pyBM 062 not being honoured||Jan 31 10:16||1|
|python IDE||Jan 31 10:15||2|
|My BM is connected to one peer twice||Jan 30 06:36||7|
|Support request/Bug report: keys.dat gets corrupted when running out of disk space||Jan 29 15:44||2|
|Feature request/idea/suggestion: user-defined data directory (command-line argument)||Jan 29 15:16||2|
|GUI dontsendack||Jan 29 05:15||1|
|Another message problem||Jan 29 03:49||3|
|Message deletion broken||Jan 29 00:28||3|
|bitmessage on android device||Jan 29 00:03||1|