Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]

[Chris Murphy]

On Jan 26, 2014, at 11:35 AM, Simo Sorce <simo at redhat.com> wrote:

> On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
>> On Jan 25, 2014, at 12:55 PM, Simo Sorce <simo at redhat.com> wrote:
>> 
>>> The reason is simple: lot's of software *changes* data as part of its
>>> normal functioning, including and often in rollback-incompatible ways.
>>> 
>>> You cannot assume that upgrading a program that uses a database X from
>>> version A to B can still work if you keep database X unchanged and then
>>> rollback from B to A. Lot of applications apply changes to database at
>>> upgrade time, either in the rpm scriplets or automatically as soon as a
>>> new version binary is run.
>> 
>> I wouldn't ever expect this with a minor version or security update.
>> I'd consider it a complete betrayal of software versioning to do this.
>> In fact in certain instances of major version changes, downward
>> compatibility of the file format is expected.
> 
> And who ever said 'minor' version ?

I'm saying it. I don't expect the behavior you describe with minor version or security updates.
> 
> However I've done this with minor versions too with internal databases.
> There is no betrayal whatsoever, major versions are introduced when you
> make user-visible changes or you break an API/ABI, you do not
> necessarily change major version for some internal change.

Again, are we talking user data or configuration files? 

If a minor version update of LibreOffice were to read my documents and write them out in a new format that the prior version could not read? I'm actually confused by how I'd react - honestly. I'm not sure if I'd file a bug with "this must be a bug, is it intended" or if I'd come out a public list with guns blazing and accuse the development team of gross incompetency (and that, honestly, would be kind language).


>>> It is basically impossible to find applications that handle the case
>>> where you downgrade, in any more graceful way than punting and
>> failing
>>> to start in the *good* case. In the bad case they start and trash
>> the
>>> database.
>> 
>> I guess I'm not really following. Do you have a for instance?
> 
> At least 3 or 4 applications I am involved with did this kind of
> internal changes.


I still really have no idea what sorts of changes you're talking about. Maybe database people are really tolerant of format changes compared to average Joe user's expectations of downward compatibility with music, movie, and various document formats? If so, we're talking about different contexts.

> 
>> Because off hand this sounds like a kind of sabotage to me.
> 
> No, it is just normal, everyday, software development.
> 
>> If it's throw away database info that can simply be reconstructed I'd
>> probably tolerate it. But for that matter, such things should go in an
>> defined cache location so that it's not even being backed up.
> 
> In some cases it is data that can be reconstructed, so all you need to
> do is to manually blow away the files and let the app rebuild them. In
> some cases that also have additional inconveniences. In some cases it is
> not data you can or want to throw away.
> 
>> But important user data having it's format updated in a way that makes
>> it incompatible with the previous minor version (same major version)?
> 
> So ?
> It is only visible if you downgrade which a lot of software do not
> support and explicitly so.


The right way to do file format changes is you design the new format. And in a minor version update, the application gains the ability to read the new file format, but still writes the old file format. The major version upgrade of the application is enabled to write the new file format, while it can read either old or new formats.


>> I'm snickering at the language that would ensue in the proprietary
>> software world, if I'm not totally confused about what it is you're
>> suggested is fair game. It'd be the sort of language you wouldn't want
>> your teenager or grandmother to hear.
> 
> ??

If Adobe Photoshop version n.1.0 started to write out Photoshop documents in a manner that n.0.0 could not read, 100% of users would call it a major bug, and it would escalate into vicious name calling - not just of Adobe the company and its shareholders, but specific individuals would get called out like an old Western gun fight. It would be nasty. It's a scary and hilarious mental exercise to think of what might happen but also ridiculous because of that. It simply wouldn't happen because of the holy hellfire that would ensue. New swear words would be invented by end users.

About the closest thing I can think of was almost 10 years ago when Nikon "encrypted" their white balance metadata in Raw files, instigated after a camera firmware update. The language used by professional photographers started out with "WTF this is bullshit" and escalated from there. If I repeated some of the common phrases from respected professional photographer colleagues of mine on this list, I'd probably get kicked off. The language was absolutely deserved and it was caustic.

Breaking downward compatibility in file formats for regular Joe user is courting public relations disaster. It can kill a product. Even Microsoft doesn't do this lightly. They've had now many file format changes of Word in how many decades? I can count the format changes on one hand. It's bad enough to make a file format proprietary to a particular application, but for an application to effectively make the file format proprietary to older versions of itself? Yeah, grossly incompetent from my perspective. Such things must be planned well in advance and made as painless as possible on the user.


Chris Murphy