They lack knowledge of revocationbase_priv, right? So how can they calculate it?
revocationbase_priv = revocation_basepoint_secret
Commitment transactions are asymmetrical. Here's what happens when A wants to update.
A constructs B's commitment transaction. Let's assume that it has only 2 outputs ("to_local" and "to_remote"). "to_local" output is delayed. "to_remote" output can be spent immediately.
In B's commitment transaction, "to_local" can be spent by B after a delay and "to_remote" refunds A their coins. In this case,
A uses their "revocation_basepoint" and B's "per_commitment_point" to calculate the revocation public key.
A sends "commitment_signed", which includes the signatures for that transaction, to B. Once B verifies if the signature is valid, they can send "revoke_and_ack" which includes "per_commitment_secret" used to generate "per_commitment_point" for the previous commitment transaction, and "next_per_commitment_point" which A will need in the future to construct the next B's commitment transaction.
type: 133 (revoke_and_ack)
data:
[channel_id:channel_id]
[32*byte:per_commitment_secret]
[point:next_per_commitment_point]
A is now able to generate revocation private key for B's previous commitment transaction as they know B's "per_commitment_secret".
B repeats the same process for A's commitment transaction. They use B's "revocation_basepoint" and A's "per_commitment_point" for the revocation public key to lock the "to_local" output.If A broadcasts their previous commitment transaction, B can spend A's "to_local" output immediately using their revocation private key, which includes A's "per_commitment_secret" and B's "revocation_basepoint_secret".Note that A and B don't send (un)signed transactions between each other. They only need to exchange signatures as they can construct each other's commitment transaction at any time.
The committer is safe as long as they don't publish that old signed transaction. What I don't understand is what will they reveal if they do broadcast it. According to my understanding, the other party needs to somehow work out the private key of revocation_pubkey, which is revocation_priv.
Nothing is really revealed at that moment. Both parties can reconstruct both commitment transaction at any time. However, they can't publish the other party's commitment as they don't have all signatures. Once the commitment transaction is broadcast, it can't be replaced*. Both parties have everything they need to broadcast a penalty transaction before the outdated commitment transaction is broadcast.
* - it doesn't make sense to replace the current commitment transaction using RBF with some old one paying a higher fee as its "to_local" output can be spent immediately by one of the parties anyway.
); one random idea would be to maybe recreate the onion services (since then you get new addresses). 
