On Wednesday, August 21, 2019 1:13:03 PM MST Przemek Klosowski via devel wrote: > On 8/20/19 11:15 PM, John Harris wrote: > > > There is no significant fire risk from this. It's just not good for the > > laptop. There's not exactly a temperature range that can cause damage, > > but > > there is a nominal range for each individual chip, and a nominal range for > > the entire system based on that. > > > You're right that fire is not the principal risk: instead, it's cooking > the chemicals in the LCDs and batteries---not the chips, which typically > have operating maximum temperature of 80C. The LCD operating temperature > is typically up to 50C, and a typical absolute maximum temperature is > 60-70C (*). The batteries have similar limits. Solomon reported burning > sensation, which typically means 60C or more. That isn't really the case for LCDs either, which are normally up to +70C on laptops. As for the batteries, it would wear them out a little more quickly, but that'd be about it. Lithium-Ion batteries in consumer laptops, in the US market, are required to have a temperature sensor and to cut off before the maximum tolerable is reached. > > I think we can all agree that shutting the system down is not the > > appropriate behavior, right? > > I would prefer a suspend---hit a key or move a mouse and see the prompt > again. Still, what's wrong with a quick reboot? The additional time from > power up to disk decryption is typically short, unless we're talking > servers with tons of secondary firmware. I think Fedora should optimize > for laptops/desktops, so if we had to chose one default I would vote for > sleep, or shutdown if sleep was not available. Suspend would be a great solution, I don't really have any issue with that, so long as it is not the default. Then again, what you're talking about wouldn't affect suspension, are you referring to hibernation? Even if that were the case, that Fedora should be optimized for laptops/ desktops (Which I would have to disagree with, at every stage. Fedora is a general purpose distro), I would disagree with this being the default behavior for desktops, and possibly for laptops as well. > > Why would this behavior be in any way desirable on a desktop system? A TPM > > or other hardware key storage does not solve the same problem as asking > > for a key to be entered to decrypt. > > > but it's less secure---the decryption password hashes (**) have to be > present on the media. Bitlocker in TPM mode has the secrets locked in > the TPM, and as an added benefit uses the 'enterprise' authorization > scheme, with revocation, recovery keys, single logon (no separate > decryption and login credentials), etc. You wrote that bitlocker > 'configured properly ... simply shows a prompt forever', but I think > that the current best practice is to use TPM, in which case the system > proceeds to the login prompt, and the full decryption is only done after > user authentication. I think that's how FileVault in MacOS works, and > perhaps Linux is also heading this way. That's not true. I don't know about how Bitlocker stores keys on the TPM, which is Windows only and does not affect us at all, but here's what you need to know about TPMs. A TPM is just a hardware key storage device. That's it. It has some minor added functionality to verify signatures, but that's all. Having Bitlocker in TPM mode doesn't change whether or not a key is required to be entered, that's a different setting. There are two different things that you're configuring with Bitlocker there. One is ensuring that system has the right keys to be able to decrypt the drive, the other is ensuring that the user running the system should be able to decrypt the drive. I can say, without a doubt, that Linux is not heading that way. It will always depend on how you've configured the system, and what you're trying to ensure the data is protected from. -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> Splentity https://splentity.com/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
