Fixing issue #262 & #263, bad keyfile permissions. #262

2013-06-26T14:39:13+02:00

fiatflux commented

2013-06-26 14:39:13 +02:00

(Migrated from github.com)

This spits out a warning to the console, but ideally it would also
issue a warning to the GUI for those who didn't start it from the
console. N.B. the warning is a one shot thing, since it fixes the
problem in a way essentially undetectable in the future, so it
should be done right if it is to be done at all.

Maybe we should even disable all keys automatically if the keyfile
is found in an insecure state.

This spits out a warning to the console, but ideally it would also issue a warning to the GUI for those who didn't start it from the console. N.B. the warning is a one shot thing, since it fixes the problem in a way essentially undetectable in the future, so it should be done right if it is to be done at all. Maybe we should even disable all keys automatically if the keyfile is found in an insecure state.

Atheros1 commented

2013-06-26 20:14:10 +02:00

(Migrated from github.com)

I will be able to test this more extensively Thursday and I would expect to merge it then.
Thank you

I will be able to test this more extensively Thursday and I would expect to merge it then. Thank you

fiatflux commented

2013-06-26 22:34:02 +02:00

(Migrated from github.com)

@Atheros1, I'm really thinking this should disable all keys before it gets merged with master. It's early in the lifetime of the project so nobody should be using this for highly sensitive communication yet, and manually enabling keys people don't consider sensitive or compromised is a pain, but I think it's worth sticking to paranoid practices from the beginning.

Atheros1 commented

2013-07-05 23:43:34 +02:00

(Migrated from github.com)

I've tested a compiled EXE on Windows and found no problems although looking at the code, it looks like it doesn't do anything special in Windows, does it?

@fiatflux Obviously it is good to be paranoid about security but we can't disable people's addresses without telling them and letting them re-enable them. This will cause people to miss messages (until they are retransmitted). But it isn't just that almost no one will notice that they need to re-enable them, it is that of those who find out, no one won't re-enable their addresses which means that it will have provided no attack mitigation in the first place.

I've tested a compiled EXE on Windows and found no problems although looking at the code, it looks like it doesn't do anything special in Windows, does it? @fiatflux Obviously it is good to be paranoid about security but we can't disable people's addresses without telling them and letting them re-enable them. This will cause people to miss messages (until they are retransmitted). But it isn't just that almost no one will notice that they need to re-enable them, it is that of those who find out, no one _won't_ re-enable their addresses which means that it will have provided no attack mitigation in the first place.

fiatflux commented

2013-07-10 21:53:36 +02:00

(Migrated from github.com)

Sorry for the delay. I'm back to having a bit of free time and network access.

Indeed, the important bits of this don't touch Windows.

I suppose you're right about how the users would react to this. The poses the question, though: what is the right way to revoke keys? (For future consideration.)

I have updated this branch to reflect your input. FYI, I don't want to redo logging here so this branch now contains commits from fiatflux:no_propagate_loggers, which has its own pull request.

Sorry for the delay. I'm back to having a bit of free time and network access. Indeed, the important bits of this don't touch Windows. I suppose you're right about how the users would react to this. The poses the question, though: what is the right way to revoke keys? (For future consideration.) I have updated this branch to reflect your input. FYI, I don't want to redo logging here so this branch now contains commits from fiatflux:no_propagate_loggers, which has its own pull request.

This repo is archived. You cannot comment on pull requests.

No reviewers