Actually I am really interested joining! Alas there is the 5 days rule: "If you want to begin sth, do not delay too much, else..." and I currently have some pile of tobedone-things and it should not grow but shrink :) Still, some "reading and pre-probing" should be possible. Luckily in this thread you linked some initial reading for this...
Great project!
I am surprised to see the actual "telescope" being a metal pipe with a small funnel - there is no satelite-DISH-reciever-thing ! I have to dig deeper... one day...
Btw I was hesitating to fetch the pdf, because I had to allow javascript for both google and gstatic on my computer, which I normally would not do. Why is it, that following a link to a google drive file needs this local execution of code stuff instead of simply delivering the file? For public openly accessible stuff this feels very weird to me ( comparing to simple (s)ftp file fetching)
thank you... but did you try that in practice?
For my system it still ocntinues to leak into a new created writable version of that file!
calling truecrypt will results in this:
(truecrypt:29720): Gtk-WARNING : Attempting to store changes into `/home/tverrbjelke/.local/share/recently-used.xbel', but failed: Failed to rename file '/home/tverrbjelke/.local/share/recently-used.xbel.I2I27W' to '/home/tverrbjelke/.local/share/recently-used.xbel': g_rename() failed: The operation is not permitted
(truecrypt:29720): Gtk-WARNING : Attempting to set the permissions of `/home/tverrbjelke/.local/share/recently-used.xbel', but failed: The operation is not permitted
(truecrypt:29720): Gtk-WARNING : Attempting to store changes into `/home/tverrbjelke/.local/share/recently-used.xbel', but failed: Failed to rename file '/home/tverrbjelke/.local/share/recently-used.xbel.QVH27W' to '/home/tverrbjelke/.local/share/recently-used.xbel': g_rename() failed: The operation is not permitted
(truecrypt:29720): Gtk-WARNING : Attempting to set the permissions of `/home/tverrbjelke/.local/share/recently-used.xbel', but failed: The operation is not permitted
tverrbjelke@espen:~/.local/share$ ls -l recently-used.xbel
Not with TrueCrypt. You can just ignore the warnings (if it doesn't cause a crash). "chattr +i" makes a file really read-only (you can undo it with "chattr -i"). GTK library wants to write recently accessed files there, and fails, emits the warnings. It's safe to ignore them.
OK I did that and the result was the above output.
And then still in same truecrypt session I saw my recently used file - while the bookmarking file still was empty.
So closing truecrypt reopening the recently used files list was empty.
So that seems to work. thx
Question for me is, how the hell can a normal process trigger root-owned read only filed to becom overwritten and chowned to normal user? What is GTK magic doing there?? I dont understand the above session! maybe someone can explai that to me?
-> select file -> ok -> select -> is there somethin in recently used?
YES! WTF?
on the console I see the following message:
"(truecrypt:29437): Gtk-WARNING : Attempting to read the recently used resources file at `/home/tverrbjelke/.local/share/recently-used.xbel', but the parser failed: Failed to open file '/home/tverrbjelke/.local/share/recently-used.xbel': No Permission."
> tverrbjelke@espen:~/.local/share$ ls -l recently-used.xbel
I filled the forms and I saw you mention use of the tor-bundle.
Anonymity is very hard to archive. So if you guide people that need it, be very careful!
PLEASE provide them dedicated instructions to embed that bundle inside/behind proper firewall / virtual machine. Otherwise they can easily be trapped by some leaking streams (e.g. tcp/dns) outside tor to identify their IP. That all must be blocked! Hope to hear from your project.
What I see is exactly false promises, lack of documentation and much innocence at the struggling users. Users try to establish privacy, use good 'ol Truecrypt. The average joe then trusts the promises, sees the "no history" checkbox, thinks he has a choice, but he does not - it's leaking and he doesn't know. And some user indeed find out that there is a leak. You can look in forums to see demand for solutions - and the many efforts to give advice. Often also false promises. Which is worst.
Truecrypt claims to offer features (no history), and officially worries about plausible deniability. And then you see practically it's all a huge mess. And I really blame them for giving false promises.
And yes: we could keep on to pass the buck, but TrueCrypt fails epically ignoring this issue. As I state, there would be true solutions possible to circumvent this leaking nightmare. If they wished, they (TrueCrypt) could fix it themselves (e.g. using another way of file selector).
If that were my project, I would do something against this and not ignore (for years).
And doing nothing will not help anybody. So I tried to give a practicable workaround until someone fixes the mess.
Well, you shouldn't be running it as root anyway (I'm not sure why you would) -- I just installed it on this laptop (Arch Linux) to test and it works just fine as a normal user.
In addition, this would still not be an issue if 1) you were running it as a normal user and/or 2) DACs were properly set.
