There is a live proposal right now, by one of the Debian apt developers, who was just here a couple days ago talking about it. I agree, it's not clear what's happening yet, but signify-style apt signatures are not a past-tense thing right now.

I don't want to reopen a can of worms on that very weird age vs. PGP thing you wrote (Debian isn't going to use age) but again, I think you should correct it, because it openly advocates for malleable unauthenticated encryption, which beclowns the rest of the points it tries to make. If you want to recover from single (or multiple) bit errors in your ciphertext, you don't relax authentication of your ciphertext; you forward-error-correct it.

The proposal has no place to go at this point. It may come back in the future, but right at the moment it is effectively dead.

If you are doing FEC then you need to decide how many bits you are going to be able to correct. That determines the amount of redundancy you need. Media problems generally come in physical media sized chunks, often adjacent. Hundreds, thousands or millions of bits might be involved. FEC is not a magic bullet for data loss, particularly in this case. Usually the best you can do is to recover the good parts and age deliberately prevents you from doing that.

You can run chacha20-poly1305 decryption without verifying the MAC, and accept that an adversary can accurately bitflip any and all bits they want. Normal tools don't have command line flags for that, but a recovery tool can do that no problem using the same exact code as age.

If that were true, would that then mean that age would be malleable by flipping around and deleting and duplicating blocks? How does it ensure continuity without preventing recovery of blocks subsequent to the bad one? I have not dug into the age code to figure out how the encryption works so I am guessing here.

I'm not sure you understand what the previous commenter was suggesting. They're saying the receiver of an `age` message could, in theory, skip authenticating the ciphertext. They would have to do so deliberately (so deliberately that the code to do it doesn't exist), and the entire point of doing so would be to defeat message security in an attempt to do data recovery.

I think you should probably dig into the age code before writing posts about why PGP is better than age. The question of whether adversaries can modify age messages in transit is a pretty basic one.

The actual damaged 64K age blocks would likely be unrecoverable after the start of the damage unless the chacha20-poly1305 ended being self synchronizing as it was used (as opposed to the CFB that OpenPGP specifies). The question I can't answer is if the undamaged 64K age blocks would then be recoverable. There might be just a counter, but you could instead (also) make a particular block dependent on the previous one(s).

Do you understand that chacha20 is CTR? A bit flip only affects that single bit, does not propagate to any other bits?

From that can I get that an age recovery utility would need to detect missing data and would then need to insert dummy blocks (or the equivalent)? I guess there would have to be an minor element of brute force involved as there would be no easy way to distinguish bad blocks from the blocks after the missing chunk.

The major concern is only about long term stability, with people starting to talk about stopping things, some paranoia kicked in.

'age' is still quite beta, so not sure if it's entirely worth the switch. But yeah I guess the long-term archival is something that I hope to have.