This error basically happens all the time. A working colleague said it is most likely related to the fact that I used an already existing GPG-key instead of using gpg-js (or what library passbolt uses) to generate the key.
I am a bit surprised, why would passbolt not support any GPG-key?
Hi @robstoll Welcome to the forum!
How about this: Unable to store an entry using an url with ip it includes the NetworkError you are describing. Suggestions have to do with modsecurity security settings.
thanks for the link, I doubt it has to do anything with modsecutity though. if I generate a GPG-key via passbolt, (for s as different user) then the export works.
Thus, I still hope that passbolt can confirm whether GPG keys not generated with gpg-js can be used or not.
@robstoll can you share a copy of the public key, or at least it’s properties? Maybe it doesn’t validate for passbolt (like old algorithm), or there is a time issue (e.g. key created “in the future”), or some other issues (e.g. multiple keys in one block).
However I don’t see how Exporting passwords fails with NetworkError when attempting to fetch resource error is related with the key setup. Moreover as Garrett mentioned, NetworkError is, well, most likely a network error.
See also a similar case:
thanks already, I’ll post it later on.
as additional information, I am perfectly able to login, create, modify, delete passwords, share them etc. only the export fails.
network error sounds like network error but maybe it is related to a combination of own server cert and own gpg-key. it’s just strange that the export works on the same server (own server cert), when the gpg key is created via passbolt
oh and what I completely forgot to mention, it used to work but I am doing the export very seldomly. Is there a way to change the gpg-key in case the algorithm is the problem (without creating a new user).
At the moment it’s not possible to rotate keys without writing something custom.
To me it seems if there was a problem with the key it would be a broader problem. But the comparison is between two servers.
The modsecurity is maybe throwing a false error and intermittently catching something it didn’t need to based on a string sequence, which is a common problem with it.
If there was no NetworkError, it seems the key is fine otherwise?
I took a look at the github issue and also installed the chrome extension (so far I used Firefox) in order to also see the error. Now I can at least see where it fails:
https://example.com/resources.json?api-version=v2&contain[secret]=1&contain[resource-type]=1&filter[has-id][]=29f4cf71-2126-4c7c-9af0-b26de93bbee9&... and many more filter[has-id][]
The URL length of 2901 could be too much I figured, as there (used to be) a limit of ~2400
And indeed, if I export less passwords at the same time, then it actually works 
So it was only a coincidence that it worked with the new user with a passbolt generated GPG-key because I did not have as much passwords there as with the real user.
So this actually sounded like a network problem (I am glad I used the firefox extension as well, the chrome extension only reported unexpected error) and indeed, I found the client sent too long URI in the nginx. Increasing
large_client_header_buffers 4 64K;
did the job.
Glad to see that it is not related to a custom GPG key.
And thanks for your help @garrett and @remy 
2 Likes