yeah, well, they might not be ‘issues’ in the true sense of the GitHub meaning, but having to rewrite many configurations that have been functioning over the last few years does feel like that.
tbh, they might actually be issues in card-mod now, I am not even sure just yet, because not sure we can find the correct syntax.
Also, we are not allowed to discuss this in the beta channel, so even though I posted about it in the card-mod thread, many people not in #beta simply weren’t aware. And because of that are bitten upon release.
I want to address a few comments I’ve seen here. I won’t single them out, because I want this to be constructive, not a complaint.
The “official” response to the concerns about the new backup process was polite and to-the-point, which I appreciated. Asking for more information was a good first step. One question, however, got my attention.
I’ve worked in IT a long time, and I’ve been involved in development on lots of different projects. One of the things which I’ve learned is a very bad sign is when developers start asking customers “Why would you want to do that?”
Yes, I used the term “customer.” Whether it’s commercial, internal-use or open-source, development efforts are pointless if people don’t want to use the product. I’ve found it’s very helpful to get the development team accustomed to calling their users “customers,” even if they’re not actually paying.
I need to stop here and say that HA is a great project, with a skilled and dedicated team. It’s just that some of the signs are pointing in the wrong direction. I hope this concern is proven wrong.
Believe me, it feels much better to hear customers singing the praises of a new release which makes their lives easier, than b*tching when it goes the other way.
This is where I don’t agree. Surely a good first step would be to ask before delivering?
(Which is why I called it ‘slightly ridiculous’)
At least one comment here if I remember correctly said that the beta gave lots of feedback about the encryption issue but it appears if that was so, then it was ignored.
But I want to have both, storing on NAS and on local ‘disk’ as well, which Samba-Backup does automatically.
I want to have the possibility first to store/restore backups if NAS is not available.
Agreed, there should be an official statement in order to stop the encryption discussion here. Making faults is not that bad and can happen. I would love to give beta testers in future more voice heard. A lot of “hot” discussions after a release had also been “hot” discussions already during beta testing on discord. Beta testing time is short, which is not bad as many things get fixed very fast, but if big concerns are identified I would love hold back things in future.
On the whole discussion on broken changes and custom components.
I appreciate that the core developers cannot support or guarantee or even be aware of all the many custom components.
But there is something that can be done.
I was release manager for many years for the TWiki and later Foswiki open source projects (Perl). And they are systems with a strong plugin community as well. The plugins were very equivalents to integrations in Home Assistant.
The core team supported around 20 plugins which were distributed with Foswiki.
And then we had an official API which was a list of official function calls and an official data structure of the document object. These were considered holy. We did not change them ever. If we enhanced them we always made them backwards compatible. Only if a security issue was involved would be break things.
Most plugins used these APIs. And most plugins never broke for this reason. A number of plugins used non API function calls. Nothing prevented a plugin to do that. But the plugin author was on his/her own. No support. No pre-warnings. And as an admin user you quickly learned to steer clear of plugins that used non API calls which was easy to inspect in the code as all API calls had names that identified them as API.
Home Assistant should consider to better define API for integrations. Both the supported and the custom. And such API should include a subset of the CSS names so that things like colours of icons etc have names that never ever will be changed. If you mod beyond the API you ask for trouble.
I’ve only used it to migrate to new hardware in recent times.
However,
I am ultra cautious on installing updates - never pull in a ‘.0’ update (or only if I am super sure of it, or it has been out for a couple of months).
Last time I restored, I did it for a single add-on.
I do have a backup strategy that has 7 days & 3 weekly (for when you don’t notice something has broken immediately). Held in differing locations (local, local NAS, cloud).
Encryption of Backups: Apologies, but when such significant changes are made, backward compatibility must be ensured over several releases. And features like encryption should be optional and configurable by the user, allowing them to be enabled or disabled.
Why is encryption mandatory? Is the ‘Home Assistant Cloud’ not secure?
Every user should be able to decide for themselves whether and how to encrypt their data…
Requiring encryption keys for backups is incredibly frustrating, and I urge you to backout this change ASAP.
End-users are the best to decide how to keep their data secure.
I am a data-security professional, and the best way I choose to keep my data safe is by making sure my backups are accessible. This means ensuring their reliability, and I choose to keep mine unencrypted to increase reliability.
I am the best person to decide my data-security practices. I am more than capable of keeping my backups safe.
By requiring encrypted keys on backups you are only requiring us to find non-standard backup solutions.
Please make the encryption keys on backups OPTIONAL.
I believe that users should have the option for having optional encryption for local backups but, with regard to the above point:
Nabu Casa wants to be able to prove that there was no way they looked at your personal data in the event that your privacy is compromised. They also want to ensure your data is safe if they suffer a data breach. I completely understand why they want your data encrypted before they store it.
Whole restore - About every 2x years.
Single file extract - About every 2x months.
Main use case is unpacking the *.tar.gz to get direct access to a config file to check against the current version - useful for debugging, and general version control.
I also sometimes uses the *.tar.gz to help configure a test pre-production install running on separate hardware (e.g. testing, Beta version, new ideas).
There are other uses - unpacking a backup is the only way to extract Mosquitto MQTT Add-On system_user.json “system” account credentials:
Whole backup restore has only been used for hardware upgrades.
Modern uSD cards are pretty reliable, and NVMe even more so.
I well understand the “plausible deniability” protection of a hosting provider from user content (“no access, no subpoenas”) for cloud backups (and UK Legislation) HOWEVER not being to unencrypt a local backup from my own hardware which was created using a standard FOSS library is a very red flag to me.
One major point of FOSS tools is “many eyes make all bugs shallow” (ESR Linus’ Law), but specifically for crypto, I’m going to quote Bruce “Schneier’s Law”:
Please fix initialisation vector entropy, fix file padding, and fix compatibility with standard crypto tooling. I’d prefer AES-256, but get low-end hardware will taker longer than AES-128.
Hello to all and at first a good and happy new year!
What I am missing at the whole discussion of encrpyting backups is to use
generated keys and certificates by the user.
I am sure some and in my opinion not so less users have their own CA (Certificate Authority) or connected to a CA.
So the usability would increase in this case extremely, if users can take her own certificat/key pair.
As conclusion I recommend to “allow” the usage of own certificates
and - of course - allow users to disable encryption.
Settings → System → Updates → 3-dot menu → Join beta channel
This way you can get pre-release beta versions to test and provide feedback to the devs. I had set up a second Home Assistant server to test beta releases, but since the feedback loop is Discord, I won’t bother. Discord is like a room full of toddlers, each trying to be louder than the others in the same room.
Often after updates of HA, some AddOns or intergrations,
When the system no longer works as originally intended after updates to integrations or add-ons,
When I made mistakes during major changes.
I keep the updates for 90 days, regardless of whether it’s sensible.
A 1TB SSD is connected to the Raspi4, no matter how sensible that is - it was cheap. On the NAS, it doesn’t matter…
Data is stored twice, on local SSD and remotely on NAS.
Fix issues in configuration files.
It depends on what I have changed and whether it works. Often after an update to a new HA release.
