Actually, the encryption in HA uses Securetar , which uses python’s cryptography library. Cryptography is not rolled by the community or the HA developers. Many people use this and it’s a proven library that works, they aren’t rolling their own encryption. This quite simply is a bug in securetar that needs to be fixed, nothing more.
2 Likes
Just wanted to chime in a bit later. After it was confirmed that custom backup solutions were untouched by the new mandatory encryption I took the plunge with 2025.1.1.
What can I say - it is all working. My first autobackup went smooth as well. Unencrypted. 
I think in our first shock (not reading the small print) we might have overreacted a bit. 
I really hope:
- that encryption can be optional within the inbuilt backup tool
- that schedules can be more flexible
- that an optional (not default) backup before update system could be reimplemented
- that custom backup tools keep working
Many thanks in advance!
7 Likes
You don’t run Frigate, do you?
2 Likes
If it does contain any sensitive or private information it should be encrypted. This could be for example passwords/secrets like mentioned in the blog post. 
Your backups not only contain the access credentials to your smart home devices but also the history of your home, and no one should be able to access information that sensitive! Ever!
You will find that any modern OS will (mostly by default) offer you an encrypted installation - and this is what one should do in 2025. Having for example a laptop, phone or usb sticks containing private without encryption is something negligent because they can easily disappear (and appear again?). For companies based in the EU encryption is mostly mandatory if they process any personal data. 
Also talking flash here you might want to use encryption actually for the pure reason not being able to (really) delete data (contained in flash cells) anymore like we could do in the old times on hard disks due to the nature how flash storage works. 
Beside you might think the controller in the SSD that is “good enough” for the encryption - but we know better today: Self-Encrypting Solid-State Drive Vulnerabilities | CISA (most serious OSes actually also disable this hardware ssd encryption function by default). 
Yes, it’s a abstract thing. I know people that used unencrypted/open WIFI and said it’s all they need and it’s easier for them because they don’t need to remember a password. 
It’s very difficult to argue to people that only see the hassles (need to remember a password) and don’t see anything visible improved (an encrypted WIFI doesn’t have visible benefits to a open WIFI for a user till the moment…) 
1 Like
Sigh. We are not over reacting. And I’m betting you would be a bit more annoyed if you understood the actual issues, Read this for quick summary: 2025.1: Backing Up into 2025! - #568 by tom_l
Sure you can use your existing backup method - for now. It will eventually be depreciated though and we would like to see this dogs breakfast fixed before that happens.
12 Likes
Tom, I think you’re still taking that out of context.
The exact quote that you keep going back to that started the “deprecation of addons”, mentions having a replacement before that happens. I.e. Moving from the supervisor to being in core, which still supports unencrypted backups.
Not speaking about overreaction, only about the “deprecation of the handlers” that custom addons use.
Yes I understand that, however on further questioning the developer in question said backups would always be encrypted. And if a new integration wanted to save it as unencrypted it would have to be decrypted first. Which is bonkers. Not just for the waste effort but it would require the key to be stored in the integration if this was to happen automatically.
8 Likes
I don’t see any mention of that in the conversations.
1 Like
I noticed that the dropdown list of a dropdown box is stuck instide the dialog frame. It only shows 2(-ish) items. It is not very convenient to use like this.
I am pretty sure that at some point the list would just expand outside the dialog box and show about 10 (I guess), but I don’t know if it is new because I don’t visit this screen often.
The bit about decryption before downloading has mysteriously disappeared, or maybe I saw it in one of the other channels.
3 Likes
He’s correlating the existing process to the new process, implying that it hasn’t changed for the new automated backups. Basically he’s saying “The new stuff uses all the old stuff really far under the hood”. He’s reassuring that we will have the same output.
‘never mind’ was the important part of that sentence.
1 Like
Yes, but this is not related to the addons or any new features that may or may not replace those. And this still doesn’t relate to the existing services from hassio.
The context in question is about handlers the addons use, which should not be correlated to existing services (which all support no-encryption): hassio.backup_full, hassio.backup_partial, backup.create, etc.
It’s not going to be add-ons. It will be integrations. Supervisor control will be depreciated.
If we do not get parity before the existing system is depreciated (and by the comments above we wont) then there will be more pitchforks. Hence trying to impress the need for this before it comes to pass.
We have already lost the ability to backup add-ons which has been a right PITA for the z2m 2.0 release and could cause data loss for database add-ons. Have you actually tried doing a manual update of an add-on under the new system using the GUI?
You are forced to set up encryption and a schedule before you can delete that unwanted service and perform your manual partial backup. That is by my definition a complete dogs breakfast
12 Likes
And under the hood, you can create unencrypted backups. That functionality exists and integrations will have access to it. The integration in question when we everyone was talking was for google cloud, which is a cloud based backup system. It was implied that this would be encrypted only, however that integration has not been created yet. Jumping to conclusions that all integration replacements for backups would be encrypted is an overstep in my opinion.
And just so you know, backup.create is an integration in HA that does not encrypt backups. It’s not part of supervisor, the action/service just currently lacks options.
Dude you are completely missing the point. That has nothing to do with what I am saying.
1 Like
What are we talking about then? Because you keep saying that it will be impossible to use these addons in the future without encryption.
I’m saying that is not true.
2 Likes
But not explicitly the other way round either, or? I read you assume, that a service based (unencrypted) way will stay or rebuild, but not that it is already proven that it will - at least I read.
In you (very interesting conversation) I can only see, that Tom reads this this way and you the other way, but without any proof, who reads it correct. Perhaps the Dev even don’t know. But from what happened, I would more tend Towards Tom interpretation.
3 Likes
I was involved directly in all these conversations, and I understand the development process and how they speak. I speak up when I don’t get “warm and fuzzies” about conversations with the dev team. I have not got the feeling that encrypted backups will be forced outside the new Automated Backups UI. I’ve had extensive conversations about this with multiple developers. I just do not see this at all in any of the conversations I’ve had. To be quite honest, I’m kinda baffled how the conversations can be seen as “forcing encryption” everywhere.
1 Like