You didn’t mean the encryption key?
It is called Password in the file. It is a plaintext yaml file. Easy to hack. An empty string does not work. Then the new backup stops working and appear as not yet setup. Tried that too.
2 Likes
Yes, opened it too. But this is the encryption key and you can change it directly in the UI.
No you cannot change the key in the UI. Try. You get a new random key generated which is as impossible to remember as the original one that was autogenerated. Buh!
3 Likes
Got it - my fault!
The .tar is not ecrypted. Also not the .tar.gz files.
Only the individual files. So taking a Quick Look you would think it’s not ecrypted.
2 Likes
It simply lacks some AI.
I really wonder if it would have been such a heck to let the backup code divert on encryption on/off depending upon the backup target if being local network or somewhere else.
For the ones who backup critical data from various software titles onto an encrypted volume on a local NAS the current solution is simply frustrating since it adds no benefit but eats up time & energy for the encoding/decoding process.
With a little sarcasm you could say a solution against a greener planet 
1 Like
“Rolling your own” doesn’t apply solely to the cryptographic primitives, but also stringing together a solution based on cryptographic primitives. Hell, I’d say especially designing something from low-level primitives. Most developers are sane enough to not design their own encryption algorithms.
It seems trivially easy to use low-level crypto building blocks, but there’s a lot of things that can go wrong – from bad key management to stuff like using derived rather than random-and-unique IVs.
5 Likes
I still don’t think it’s fair to be this upset and base all judgment on a single bug (in regards to securetar).
1 Like
Why in the world would they remove a valuable feature like this??? It was there for a reason and I always used it. Rolling back to 2024 until this backup fiasco, including forced encryption, is resolved.
6 Likes
The padding bug is one thing – the derived IV is another, which is a bigger indicator that SecureTar probably should be scrapped in favour of something else, preferably a standard format designed by somebody who was qualified to do so.
I’m sorry if the above sounds harsh, but I stand by my previous comment that bad crypto is worse than no crypto.
The SecureTar bug / bad design is a relatively minor thing, though. I’m not interested in using it for my backups, so if the HA team wants to stick with it, whatever. But I’m annoyed at the whole process around these backup changes – taking away existing functionality (unencrypted backups, backup-before-upgrade) and removing user choice. While we (for now, anyway) can create unencrypted backups, it’s gone from the UI, and having to manually create a full backup (which can’t be unencrypted) before addon updates is a LOT more clunky simply un/checking a box on the update dialog.
Initially I was pretty excited about this update, as there’s a lot of good in it, and was about to give a big thumbs up for the work on improving the backup system – making automatic backups and retention easier, and even having encryption-by-default are great ideas!
But when functionality and choice is removed, and it’s being done so hamfistedly, even when people have complained about it in the beta period? And rushing out an update when you KNOW you’ll be away shortly after, instead of simply having a quiet January and doing a better planned February release?
There’s a lot that has gone wrong here, and it’s more about communication and process than implementation.
21 Likes
Yes, you’ve made your opinion very clear multiple times. I think at this point we should wait until further notice instead of rehashing the same points over and over again. Lets let others who haven’t shared their thoughts get a moment in the sun.
+1 
I’ve already quoted Bruce “Schneier’s Law” in a previous post above, but fundamentally, crypto is so hard to get right (all the little details of entropy, in memory key management, not just padding) that the only way to know is to undertake another focused security review as has been done before by specialists.
A lot of really talented folk work for NC and care passionately about the end result - crypto is just hard.
2 Likes
Back in the day, when I was involved in commissioning and testing on the client side, the bible we all referred to was the requirements document.
The first stage in a project would be marathon consultation with stakeholders to draw up a minutely detailed list of measurable requirements, which everyone had to sign off on. From then on, a large part of my team’s job was to say to the developers “No, that isn’t what we asked for.” And to our bosses “No, that isn’t what you asked for.” Everyone hated us.
Having struggled through (most of) this monumental thread, it’s far from clear how it works in HA. OK, there’s “the vision”, and there’s the road map, but that’s all very broad brushstroke stuff. There’s beta testing, but that’s when you find out whether the features you asked for really work, not a chance to ask for something different. When were the requirements for the new backup regime actually finalised?
Back in the day, our requirements document would have said:
- Option for automatic backup before update
- Option for encryption of cloud backups
- Option for encryption of local backups
And all these would have been specified months ago.
I would like to, but I don’t see much evidence that this happened. There’s no question that users are stakeholders, but I can’t help noticing that the month of WTH and the “Understanding our Community” survey both happened in December. I would hope that requirements for something as important as a new backup regime were set in stone by September, but I somehow don’t think they were.
(Before I get jumped on, users may be stakeholders, but I do believe that open source means you can see what’s in it - not that you can say what’s in it.)
Home Assistant is an outstanding product but it has grown very large very quickly and the wheels may come off quite soon. It needs:
- Fewer updates
- Longer beta testing periods
- More advance demos of new features so that users aren’t taken by surprise
- Less attention paid to the noise generated by the forum and Discord and CES
- Requirements that are clearer (to all), earlier
</rant>
16 Likes
I think everything that has to be said about the new backup features has already been said.
But I feel there is one thing that I must convey. Users of Home Assistant use HA because they love opensource & everything about it. That means I’m in control of my system. I perfectly understand the decision of Nabu Casa to not allow unencrypted backups on their cloud system, but in my domain I can & should do as I please. I’m not running a purchased & licensed OS that governs what I do.
Don’t get me wrong, I think Nabu Casa & the whole team are awesome - but this time it looks like you are trying to control us. I think the awesome HA userbase should not stand for that.
9 Likes
But…they’re…not controlling you? As Petro has stated (many times above), they aren’t taking away your ability to make unencrypted backups. The revamped built-in function currently doesn’t have that, but the service calls and addons are still capable of making unencrypted backups on your schedule.
I commented on that in EU everything containing sensible data must be encrypted. It’s pure false statement. There is no such obligation. Similarily there is no obligation that data operator has to encrypt data backups.
The operator has to secure these data. But it’s different thing. If a company can secure the location enough the backups may be stored there in plain text.
However… it’s about operator operating on data being not the company property (applies to personal and sensitive data)
In case of my personal data, I as the owner of them can do anything with them. GDPR doesn’t apply there. Thus there is no single reason to force me to encrypt those data. I’m their owner. I decide I publish them or not, encrypt or not.
It applies to me and my family. It coůd be different when I was an operator of a hotel powered by Home Assistent sw. depending on what client’s data I would store in HA. opening windows doesn’t fall to personal/sensitive category
2 Likes
I think it would be very helpful if the Lead of Product and Design at Nabu Casa gave us an update on her thinking about how she sees the future for backups of Home Assistant.
3 Likes
I got my first error last night with the autobackup.
Not sure what to do next?
Log says Error creating backup: Error getting backup details: Backup does not exist**
**
Check the supervisor logs and ha logs for details. Check the logs around 4:45 am in both areas.