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
Petro, read:
Yes that is exactly what I am saying. And I have good reason to:
They will always be encrypted:
Hopefully we can convince the developers this being mandatory is not needed or wanted.
13 Likes
WRONG!
If someone has penetrated your security to get this far, nothing is safe. Encrypted or not.
As I understand the current (2024) external backups, the add-ons (Google Cloud, Samba Backup) first run the backup.create integration then upload the .tar file to the NAS or cloud. If the plan is to add encryption to backup.create, then unencrypted local backup would be impossible. The ability to download an unencrypted backup is a poor solution. I can understand forced encryption when uploading to Nabu Casa for their own exposure risk, but everything else should be at the option of the user.
IMO, everything local should be unencrypted, as it is in 2024.x.x, and only encrypted when uploading to the Nabu Casa cloud. Otherwise optionally by the user selection.
4 Likes
Tom, you are combining 2 unrelated sentences. This is what Iām saying!
He was assuring me that the backend did not change with that second sentence.
To be clear: He is not saying that the new replacements will require encryption.
He was assuring you there will be a replacement. You have not understood what that replacement entails.
No, he is answering my direct question:
Did the backend change?
response:
From a backend perspective of what actually created the backups, that is still the same logic, same process and same encryption used
Yes, itās hard to follow that on discord, but Iāve spoken with frenck enough times to know how we communicate.
Iām telling you, those 2 comments are not related and he answered my questions out of order.
I the user of my installation know 100% that my NAS is local and does not require obfuscatory encryption, itās two feet away from me as type this, it has a backup for true SHTF moments, in my garage, about 40 feet away.
In removing backup options, and enforcing encryption options, the obviously tone-deaf āthem/theyā aka the Home Assistant devs, are making all us users out to be imbeciles who donāt know the layout of our own systems and how we prefer to use them.
Itās not good enough doing yet another survey after the event, especially when the very same feedback was forthcoming at the beta stage, but they forged ahead with the intended ābreaking changeā anyway.
Is HA trying to force people away or trying to make things better and easier, itās looking increasingly like the former to me.
3 Likes