Note this was originally pointed out by Florian Weimer here:

https://mail.gnome.org/archives/ostree-list/2014-February/msg00010.html

https://git.gnome.org/browse/ostree/commit/?id=f2e0162846cbb84abf6fd9a38fabdfd588f4eb2f

landed which helps by ensuring we don't get directly downgraded on the same branch.  However, if an OS vendor has multiple refs available, an attacker could still force a downgrade to a semantically older branch.  Say we're running 

exampleos/stable/core

And there is also:

exampleos/oldstable/core

If there's a chronologically newer commit to exampleos/oldstable/core (for a security update say), then an attacker could just return the commit for oldstable/core.

To fix this, I think our only option is a new format for refs where the signature covers their name.  Something like:

ostree/repo/refs2/heads/exampleos/oldstable/core

Which would also be a GVariant.  And then we have a format like this:

(
 (
  s name
  t timestamp
  a{sv} metadata
  y[32] commit
 )
 a{sv} detachedmetadata
)

Where detachedmetadata would include ostree.gpgsigs, and cover the first chunk.

The other alternative is to introduce a new "ostree.refname" metadata key in commits (ideally *only* if we are using GPG).  This would then require that rather than tag old commits, we always generate new commits.

Both concepts are starting to merge the ref/commit split.  I'm not sure which I like more yet.

See also https://bugzilla.gnome.org/show_bug.cgi?id=728690

Fixed with https://github.com/ostreedev/ostree/releases/tag/v2017.9