Detail how to find and extract the master key in documentation.

[dietercastel]

I was looking around on info on where the master key is stored. The readme on the e2ee spec doesn't detail this, but imho it should. Certainly in absence of GUI-based export option at the moment as mentioned in #956

I think it should be added in this document under the section "Master Keys".
https://github.com/laurent22/joplin/blob/master/readme/spec.md

If in agreement I'll start creating a pull request to include it in the documentation more clearly. Any advice on that front is welcome. I noticed in this file https://github.com/laurent22/joplin/blob/86dc72b204c8c4af50d0d6f7d0cfe917b7f5adbe/ReactNativeClient/lib/models/MasterKey.js
that there is an SQL query for a master key. Does that mean it is stored in an SQL database? Which one would that be? How is the master-key encoded atm?

Maybe in a follow-up issue making the master-key GUI-exportable might be useful. If people want to move to a different client/implementation this would make it easier and increase the trustworthiness of Joplin as a whole.

[dietercastel]

I think this would be an appropriate label:good first issue as well.

[tessus]

@dietercastel I find it would be appropriate if people read the template, before deleting it.

[dietercastel]

Dear @tessus, I did read the template, and went to check out the discourse, which yielded nothing related to this. Since I intended to contribute, if none could help out, (by reading the code) and planned to create a PR for this issue to improve the documentation, I thought it was wise to use the GitHub Issue system as intended: to discuss issues and link them to pull requests. Unclear documentation is an Issue in my book but I do come from a security background.

Is a feature enhancement request a support question in your book?
Or should I have reported it as a bug instead?
Or should I have contacted support to report it as a security issue?

I sense a bit of build-up annoyance around all this. Maybe because people are used to using the issue system as intended. Old habits die hard and IMHO a feature enhancement request is not an urgent support question to be asked on discourse.

This information is also to be found in your favourite communication medium: discourse

[laurent22]

@dietercastel, we're still investigating how to best handle the volume of support requests. There's one simple fact: we can't handle all of it, unless we quit our job and do it full time but we need to eat too :)

So we currently have two options:

• Let everyone post anything they want and just ignore 90% of it (pretty much what we were doing before)
• Only let people post about urgent stuff - bugs and security issues.

For now we settled on the latest option but perhaps it's indeed not the best way as now many issues go like this: People ignore the template and post off-topic stuff; we close it; they complain; we have to explain, which is an even a bigger time sink than before.

So perhaps we'll go back to the previous option of ignoring most of what's posted and let it get auto-closed by the stale bot.

For now anyway, please use the forum. Doc is important and we're keen to improve it, however I'd argue that what you're asking is not as straightforward. We shouldn't list SQL queries in the doc - once it's in the doc we have to support it properly. That means for example we can't change the database structure without breaking people's scripts. So certain things, like this, are undocumented for a good reason.

But again, that could be a wider discussion better suited for the forum.

[dietercastel]

Thanks for your time and effort, much appreciated, and see you around on the forum/here. To be constructive I opened this topic on discourse as well