[Bug 1721271] Re: Bluetooth and Wifi: coexistence Problem

2017-11-23 Thread Tim Ruffing
Ah I see, yes. This issue here refers to
https://bugzilla.kernel.org/show_bug.cgi?id=197137 instead, see above...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1721271

Title:
  Bluetooth and Wifi: coexistence Problem

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1721271/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1721271] Re: Bluetooth and Wifi: coexistence Problem

2017-11-21 Thread Tim Ruffing
I'm pretty convinced that the linked upstream bug is different. It's a
regression between 4.13 and 4.14, but this here is a regression between
4.12 and 4.13. Also the upstream bug does not mention bluetooth at all.
Could you open a new upstream bug?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1721271

Title:
  Bluetooth and Wifi: coexistence Problem

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1721271/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 878964] Re: Resuming a backup with a different password should throw an error

2013-08-21 Thread Tim Ruffing
I don't think this is fixed properly.

Let me sum up the change: 
In the new function validate_encryption_settings, the first volume is decrypted 
to see if the provided passphrase matches the one from the aborted backup run.

This makes sense for symmetric encryption. However for public key encryption, 
we can just check if the recipients are the same.  There is no need to decrypt 
anything in the whole process (or do we need somewhere else?), so we do not 
need any private decryption keys.
duplicity 0.6.21 requests those keys:

 RESTART: Volumes 7 to 9 failed to upload before termination.
 Restarting backup at volume 7.
[...]
= Begin GnuPG log =
gpg: encrypted with 2048-bit RSA key, ID BA6C3E32, created 2013-08-15
KEY TO ENCRYPT MY BACKUPS (I will never use this key to encrypt anything else 
than my personal backups. I will never use this key to sign anything.)
gpg: public key decryption failed: bad passphrase
gpg: decryption failed: secret key not available
= End GnuPG log =

(Here I did not provide a passphrase. But the point is that duplicity
wants to have the private key.)

The only exception: Hidden recipients. There is no obvious solution:
 - Detecting added hidden recipients could be done by trying to decrypt, like 
for the symmetric case. But this is again not great for those who want to store 
their private keys somewhere else or for unattended backups.
 - For removed (and added) hidden recipients, one could store the recipients in 
the local cache as long as the backup is not finished. Since they should be 
hidden, that does not sound like a good idea either.
 - Or just live with the fact that parts of the backup can be decrypted with 
different keys in this special case...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/878964

Title:
  Resuming a backup with a different password should throw an error

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/878964/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs