#TIL that @GnuPG appears to use the #ustar tar archive format, likely the version from POSIX.1-1988, for #gpgtar rather than either the #POSIX or Star formats from POSIX.1-2001. Since ustar has serious limitations on filename and pathname lengths, can't store certain file types or metadata, and has a 2GB file size limit, it seems unsuitable for most modern use cases.

If gpgtar is actually using star, pax, or the GNU tar POSIX mode, it's not in the #GnuPG user documentation which explicitly says it uses ustar. I have a lot of respect for the #GPG devs, so I hope this is either just a documentary oversight or something that they can easily fix by linking with newer libraries. In either case, ustar is totally unsuitable for writing large archives to tape, and doesn't even offer the options GNU tar does for creating a separate index file, encrypted or not.

The gnutar command line doesn't offer the option to write a separate index, and requires a separate pass to list out the index. For example if you wanted to encrypt a 20TiB archive with a separate, encrypted index to make finding files easier, you'd either have to pipe tar through gpg (which can cause shoe-shining or buffering issues on #LTFS) and then encrypt GNU/BSD tar's index, or have triple the online HDD/SDD capacity of your archived data so you can tar up your files, run another pass with GnuPG to extract the index, and then encrypt both the tarball and index separately before writing them out to tape.

That seems...unreasonable. #OpenPGP doesn't support the AES-256-GCM mode built into current #LTO drives, so gpgtar needs to keep up with the massive growth of data storage capacity rather than remaining an afterthought utility. Especially for #SOHO LTO drives, the ability to write encrypted gpgtar archives and indexes directly to LTFS could be a real game-changer!