The majority of Joplin's development is carried out in the public domain. This includes the discussion of issues on GitHub, as well as the submission of pull requests and related discussions. The transparency of these processes allows for collaborative problem-solving and shared insights.
However, there is one aspect that operates behind closed doors, and for good reason: addressing cybersecurity vulnerabilities. It is imperative that these issues remain undisclosed until they have been resolved. Once a solution is implemented, it is usually accompanied by discreet commits and a message in the changelog to signify the progress made.
Typically, the process begins with an email from a security researcher. They provide valuable insights, such as a specially crafted note that triggers a bug, or an API call, along with an explanation of how the application's security can be circumvented. We examine the vulnerability, create a fix, and create automated test units to prevent any accidental reintroduction of the vulnerability in future code updates. An example of such a commit is: 9e90d9016daf79b5414646a93fd369aedb035071
We then share our fix with the researcher for validation. Additionally, we often apply the fix to previous versions of Joplin, depending on the severity of the vulnerability.
The contribution of security researchers in this regard is immeasurable. They employ their ingenuity to identify inventive methods of bypassing existing security measures and often discover subtle flaws in the code that might otherwise go unnoticed.
We would like to express our sincere gratitude to the security researchers who have assisted us throughout the years in identifying and rectifying security vulnerabilities!
In many ways I agree with all of the words, the good-will, the assessment and the positive intentions. There is just one problem, and it's a serious one.
The NSA (and similar organizations in other countries) know about these processes, and they have vital interests to undermine every widely used piece of software, not only do they get paid for it, not only do they command vast resources, and are they widely (sometimes more, sometimes less) by their government or foreign governments. They are not just hacking, pay hackers, and help each other. They do know that it is vital to work on every front. This includes writing (or contributing to) the rules of important internet standards, go to conferences and lobby for this change or against that change, provide commonly used libraries (including open source), have contacts in every circle. But worse of all this is that they - for the better of mankind - do everything to make sure that such practices will not end.
Now back to the long list of security researchers - the efforts of each one of them being very much appreciated ... in general. How many of them have a known and verified C.V. and history, how many of them might have more than just one single goal. How many of them, without any ill intentions may be gettin' paid by some project in return for some .... and how many along their lifes did nothing wrong so when bribe doesn't work, extortion may do the job.
Don't get me wrong. I am not accusing any single one of them. But even a person who intentionally contributed to the closure of three minor vulnerabilities, while being misguided in many ways, could easily contribute to keeping one other, serious vulnerability wide open.
This does not mean that you should stop doing what you do, or change what you're doing. But it means that the worldwide management of cyber in-security will not stop at the gates of github or Joplin. It is much more reasonable to believe that both of them are high on the list of targets.
Well, yes, but a lot of this is outside our control, so we do what we can do. In this particular case, we have a proof-based process, with fixes and associated test cases, that can be independently verified. Even if someone as you say found four vulnerabilities and only reported three, that's still a win, and perhaps someone else will eventually find the remaining one.
As for the security researcher identity, some prefer to remain anonymous, but I don't see how that's relevant? Note that we implement the fix - a white-hat hacker doesn't have carte blanche to change the codebase as they want, they simply provide a proof of concept, which we can check and use for our fix and tests.
This sound very easy because even a refrigerator can find a vulnerability! Thanks to all of these researchers sharing their work and thank you Laurent!
