Carsten Dominik writes: > thank you very much vor putting in the time to test the encryption > for MobileOrg. No problem - thank you for writing and sheparding Org. >> But for org files on servers we believe are not messing with them, >> this is probably in the 'best is the enemy of the good' category. >> And if we want integrity (I know, ENOPATCH), then it's probably best >> to do it outright, so I withdraw my complaint about checksums.dat >> being in cleartext. > > Is is also so that the file transfer is happening in two one-way > street. agendas.org and the agenda files and index.org are uploaded, > mobileorg.org is downloaded, and its contents are then applied > locally. Seems to be little room for problems here. The issue is that the whole point of encryption is to use a webdav server not under one's control, such as dropbox, or perhaps one accessed not over SSL. Encryption prevents the server admin from reading the bits, and that's the most important thing. But if the server admin changes the ciphertext, they can cause the wrong plaintext to appear. This is generally tricky, but it's a principle of cryptographic protocol design that one can't assume that encryption provides integrity (meaning, that just because the bits are encrypted doesn't mean it prevents an adversary from manipulating the plaintext). That said, the above is probably overly paranoid for most people. >> ~/orgtmpcrypt seems to not always get cleaned up when I push/pull. >> After a push, I found it to contain my index.org, unencrypted and 644 >> in my homedir. Probably this should go in org-directory instead >> which presumably would be protected as the user wants. > > I did not put it into org-directory because I don't know if users have > this set to an accessible place, and I don't want the push > to fail because of that. I think this is the classic security/convenience tradeoff. On a multiuser system, I think Org now puts the orgtmpcrypt file with normal umask, and that can be read by other users (albeit briefly). I suggested org-directory because someone who wants to keep other users From seeing his org bits will protect that approriately - mine is 0700. I suppose there could be someone who turns on encryption and has org files in random places but no directory matching org-directory. Getting an error seems fair enough and better than risking exposing private bits. (Again, I realize I'm on the paranoid side, but I do security professionally so it comes naturally.) > I have modified the code and hope that it does now in all cases > clean up the temporary file. Please let me know if you still > find a case where this is not so. Thanks - will do. Right now all is working well.