v1.2 transaction signing discrepancy

[ScottSallinen]

There appears to be a small discrepancy in behaviour between key signing between v1.2.2 and v1.1.6.
In v1.2, it seems users are able to submit a transaction that signs an active authority with an owner key. The v1.2 node validates this TX as okay. However, this TX does not go through to v1.1.6 nodes -- instead, they reject it due to unsatisfied permissions. The v1.1.6 nodes only seem to accept the active auth if it was signed purely by the active key.

Edit:
I found the source of the discrepancy: light validation was unclear.
However, the original issue is still something worth considering -- should the owner key be able to sign a required active permission?

Anyway, here's the actual issue for the v1.2 vs v1.1.6 discrepancy:
8942727#diff-147a7174fb705ef227e4e28b336acd4fR1659
As it turns out, light validation can not be used on an API node because it will not check the auths of an ANY incoming transactions.

Is there any chance of supporting a mode in which blocks are lightly validated (since the API is only connected to nodes that I control, and thus I know have validated the blocks), but submitted transactions are still validated in full?

[ScottSallinen]

"In "light" mode all incoming blocks headers will be fully validated; transactions in those validated blocks will be trusted "

Perhaps this needs to be updated to say "all incoming/pending transactions will not be validated either", and not just talk about blocks.

[wanderingbort]

We will fix the bug for light validation in the next patch release.

As for "oversigning" (providing owner key instead of active), it is acceptable as long as it's declared. So, the authority needed for the action could be "active" but you can still declare a higher level like "owner" and sign for it. You cannot declare "active" and sign it with keys/accounts/delays that are not part of "active"

[ScottSallinen]

Great! Glad this was actually a bug -- this makes it much more useful for my use cases.

Regarding signing an account@active permission with an owner key, I do understand you can do it if you make sure it's specified as account@owner instead. The issue our user had was signing with account@active specified in the tx.
I'm sure it would be possible technically to allow the owner key to sign it (you'd just need to iterate over parent perms to check if one signed it), but as this would be a consensus fork I won't die on this hill for this to be implemented 😄