Feb 13 08:05 [raw]
wtf is that?
Feb 13 11:06 [raw]
> wtf is that? No idea.
Feb 13 15:30 [raw]
> 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 [raw]
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 [raw]
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 [raw]
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 [raw]
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 [raw]
let me guess ... the "bug" allowed the attacker to snarf everybody's private address keys?
Feb 13 17:04 [raw]
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 [raw]
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 [raw]
Any possibility that an attacker was able to vacuum up keys.dat data?
Feb 13 17:37 [raw]
> 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 [raw]
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 [raw]
Hello, Do you think that those exploits concern only windows OS, or other OSs may also be concerned ? Thanks Harry
Feb 13 18:33 [raw]
> 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 [raw]
Feb 14 09:25 [raw]
BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw didn't broadcast ):
Feb 14 09:43 [raw]
> BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw didn't broadcast ): Well I did get it ... Peter Surda Bitmessage core developer
Feb 19 22:06 [raw]
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 [raw]
> 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 [raw]
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 [raw]
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 [raw]
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 [raw]
> 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 [raw]
Looking good and shaping up. More padlocks, hombre. Even more.
Feb 20 12:23 [raw]
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 [raw]
Noname programmer here, you have my permission to go fu^H^H^H^H^Hproceed.
Feb 20 12:48 [raw]
How often you intend to try again to convince people that anyone still gives a fuck about Pascal?
Feb 20 12:50 [raw]
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 [raw]
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 [raw]
> 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 [raw]
> 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 [raw]
> 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 [raw]
Roll my own OpenSSL? Alrighty then
Feb 20 18:05 [raw]
> 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 [raw]
> 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 [raw]
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 [raw]
it's a shame that smalltalk does not compile to native code.
Feb 20 18:40 [raw]
Ada is based on Pascal, genius.
Feb 20 18:43 [raw]
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 [raw]
> 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 [raw]
> That's exactly what BSD did. They call it LibreSSL. Forking is now considered "rolling your own"?
Feb 20 19:23 [raw]
Feb 22 14:29 [raw]
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 [raw]
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 [raw]
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 [raw]
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 [raw]
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 [raw]
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 [raw]
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 [raw]
> 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 [raw]
> Process UTF, the safety argument dies. Python 3 compartmentalizes UTF. I believe that would make it type safe.
Feb 22 15:27 [raw]
> 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 [raw]
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 [raw]
I see what you tried there.
Feb 22 15:53 [raw]
> 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.
Mar 10 18:31 [raw]
Hi, i just found out about this. Have not used BM since 4-5 months on windows.. When did this attack happen and do you have a copy of the binary? How can I see if my computer was affected by this? Greets
Mar 10 19:35 [raw]
The first tests started showing up around the 9th 10th, the main attack around 11th-12th of February 2018. However since the vulnerability existed prior to that, it is possible that someone else attacked prior to that. I don't have logs that go before 2018. Peter Surda Bitmessage core developer
Mar 10 19:45 [raw]
all objects should be parsed text only and that logic should have no connection to the GUI whatsoever. otherwise they'll just find another exploit.
|Now, following my own advice, adding channel bitmessage and general to the blacklist||May 23 15:50||9|
|hyperboria node [fc5b:acf7:9762:439c:394d:02bb:d603:05de]:8444||May 23 01:34||3|
|Feature request: delete all messages from user||May 22 10:46||2|
|(no subject)||May 22 06:46||7|
|Github Wiki complaint||May 21 08:49||12|
|EFAIL?!||May 21 08:25||26|
|ERROR - Error Processing||May 21 08:25||3|
|Curious||May 21 02:17||32|
|Is bitmessage within whonix bad?||May 20 21:24||14|
|Duplicate messages||May 20 21:08||1|
|Download of Windows binary from Bitmessage.org||May 20 07:25||3|
|How to create a "send only" bitmessage address||May 20 04:35||1|
|/join #bitmessage on eris.us.ircnet.net :6667||May 19 21:46||3|
|hey - why not make pyBM as shitty as "Signal-App" by Marlinspike ?||May 19 20:30||7|
|use Claws mail-App with pyBM and python||May 19 20:28||5|
|A question||May 18 23:24||2|
|A Few Bitmessage Internals for New Users||May 18 23:08||5|
|May 18 17:33||1|
|Ideas for countering trolls and spam||May 18 12:54||98|
|DARKNET DIRECTORY ASSISTANCE||May 18 02:25||1|
|Broadcast messages||May 17 23:24||24|
|2018 : Der junge Karl Marx -- youtube.com/watch?v=AbM76KUm4IM -- 2 hours "Le Jeune Karl Marx"||May 17 20:24||1|
|Signal-App is complete shit||May 17 20:24||13|
|May 17 19:49||2|
|OTR interception||May 17 18:00||3|
|auto renew one's canary using broadcast or [chan] ?||May 17 10:51||1|
|latest in the spy world||May 16 14:14||3|
|Curious -- GUIfied pyBM-CLI||May 16 13:47||1|
|efail vulns||May 16 13:21||1|
|how does the namecoin feature work?||May 16 07:24||3|
|Email campaign to promote Bitmessage?||May 15 18:09||1|
|NSA doesn't joke, folks||May 14 23:26||2|
|Beaker||May 14 19:27||1|
|Bitmessage Bug - Re: Now, following my own advice, adding channel bitmessage and general to the blacklist||May 14 16:21||3|
|Ideas for countering trolls and spam - technology.||May 14 16:21||9|
|BITMESSAGE||May 14 14:58||2|
|BM in firejail||May 14 14:24||1|
|Team Revenge||May 14 09:54||1|
|What are these messages?||May 13 07:57||8|
|Bitmessage Bug?||May 10 19:59||1|
|TOR -> VPN -> TOR||May 10 14:57||2|
|Bitmessage on Raspi||May 10 09:32||2|
|Bloom Filter for Routing||May 10 09:04||1|
|Alternative treatment of Bitmessage addresses for use as public channels||May 9 16:12||4|
|deterministic passphrases||May 8 16:54||21|
|nothing wrong with suicide these days||May 8 10:30||2|
|What's Peter Todd's public key?||May 8 10:27||7|
|BMinstallMenu - easy download + run Bitmessage from py source in one single menu||May 8 08:46||1|
|BMinstallMenu - easy download + run Bitmessage from py source in one single menu||May 7 18:38||2|
|Why there are so many alternative Bitmessage implementations?||May 7 18:31||14|
|modding pyBM||May 7 18:17||4|
|bm hidden service settings||May 7 10:48||1|
|bitmessage feature proposal||May 7 10:38||1|
|This shit world||May 7 07:22||2|
|Outgoing connections||May 7 04:53||2|
|"time to live" ?||May 7 03:27||2|
|OTR on Bitmessage||May 7 02:06||31|
|Newbies! READ ME! (Bitmessage Primer)||May 7 00:43||1|
|For Bitmessage Devs - GUI Interface Design||May 6 23:18||1|
|O M E G A||May 6 19:14||14|
|Bitmessage being sandbagged?||May 6 05:55||3|
|Is Peter Surda around? Why stop signing technical messages?||May 5 22:40||3|
|How to decrypt past objects?||May 5 08:18||14|
|PyBM Error - no sufficient space in / partition but /home have lot's of free space||May 4 13:42||3|
|Anybody seen this error before?||May 4 12:58||4|
|<h1>HTML tags are enabled in subject tooltips</h1>||May 3 22:17||3|
|is that right?||May 3 07:33||6|
|RE: pyinstaller binaries do not run||May 2 07:37||1|
|RE: hidden chan?||May 1 06:05||1|
|hidden chan?||Apr 30 16:15||2|
|bitmessage takes long to connect and finds only few peers||Apr 29 10:54||2|
|pyinstaller binaries do not run||Apr 29 09:43||4|
|ready-made Linux distro with BM included via TOR : "Merlot"||Apr 29 09:27||1|
|landing page - better looks||Apr 26 23:45||1|
|BMinstallMenu - easy download + run Bitmessage from py source in one single menu||Apr 26 07:02||1|