Hi Joey,

thank you very mich for the quick implementation of this feature! I have tested it already successfully

There seems to be an minor issue when I am trying to set encryptonlycreds=yes via SETCONFIG, followed by a subsequent SETCREDS:

(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> VERSION 2
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] <-- EXTENSIONS INFO GETGITREMOTENAME UNAVAILABLERESPONSE ASYNC
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> EXTENSIONS INFO
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] <-- LISTCONFIGS
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> CONFIGEND
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] <-- INITREMOTE
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> GETCONFIG encryption
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] <-- VALUE hybrid
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> GETCONFIG onlyencryptcreds
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] <-- VALUE 
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> SETCONFIG onlyencryptcreds yes
(Annex.ExternalAddonProcess) git-annex-remote-tape[1] --> SETCREDS key aes256 70482ccb1e0a0b8f8bf6f2603174d2d6f40d940033285d3ae94e7258595dca26
git-annex: getRemoteConfigValue onlyencryptcreds found value of unexpected type PassedThrough. This is a bug in git-annex!
CallStack (from HasCallStack):
  error, called at ./Annex/SpecialRemote/Config.hs:209:28 in main:Annex.SpecialRemote.Config
  getRemoteConfigValue, called at ./Remote/Helper/Encryptable.hs:297:27 in main:Remote.Helper.Encryptable
failed
initremote: 1 failed

I am not sure if this is even supposed to be supported? Let me know if I am using it in the wrong way

Downloading git-annex...
--2025-08-24 12:49:08--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64-ancient.tar.gz
Resolving downloads.kitenet.net (downloads.kitenet.net)... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2
Connecting to downloads.kitenet.net (downloads.kitenet.net)|66.228.36.95|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2025-08-24 12:49:09 ERROR 403: Forbidden.

The Download with the git-annex-install script fail, I guess because the build is failed. see: https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/

enableremote encryption changes: FAIL (0.73s)
./Test/Framework.hs:92:
initremote failed with unexpected exit code (transcript follows)
initremote baz
git-annex: There is no security benefit to using onlyencryptcreds=yes with encryption=shared
failed
initremote: 1 failed

It would be grate if you could fix that. Thanks in advance.

3x more allocations now than before. This is probably due to the switch to OsPath, which means extra copying from ByteString.

    Thu Aug 21 20:18 2025 Time and Allocation Profiling Report  (Final)

       git-annex +RTS -p -RTS find

    total time  =        0.99 secs   (989 ticks @ 1000 us, 1 processor)
    total alloc = 1,514,545,208 bytes  (excludes profiling overheads)

COST CENTRE                        MODULE                         SRC                                                 %time %alloc

keyFile                            Annex.Locations                Annex/Locations.hs:(790,1)-(806,44)                   7.1   12.9
>>=.\                              Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(148,9)-(149,44)    6.9    2.4
>>=.\.succ'                        Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:148:13-76           5.6    0.7
keyFile.esc                        Annex.Locations                Annex/Locations.hs:(796,9)-(801,32)                   5.3   10.7
ifM                                Utility.Monad                  Utility/Monad.hs:(62,1)-(64,44)                       5.1    8.7
ifM.\                              Utility.Monad                  Utility/Monad.hs:64:9-44                              3.5    8.6
hashUpdates.processBlocks          Crypto.Hash                    Crypto/Hash.hs:(103,5)-(112,76)                       3.1    0.3
inAnnex'.\                         Annex.Content.Presence         Annex/Content/Presence.hs:(53,61)-(68,31)             3.1    8.5
keyFile.anyneedesc                 Annex.Locations                Annex/Locations.hs:806:9-44                           3.1    1.0
seekFilteredKeys.exists            CmdLine.Seek                   CmdLine/Seek.hs:465:9-92                              2.8    0.4
fileKey                            Annex.Locations                Annex/Locations.hs:(814,1)-(824,41)                   2.1    1.0
keyPath                            Annex.Locations                Annex/Locations.hs:(834,1)-(836,23)                   1.8    5.9

I've implemented onlyencryptcreds=yes.

Note that this bug needs to be addressed to avoid some foot shooting with this new option: prevent enableremote changing encryption Since the foot shooting is no worse that previously possible foot shooting shown in that bug, I went ahead and added this new feature before addressing that bug.

I think I was assuming that encryption=onlycreds would use the same scheme as encryption=hybrid, so new gpg keys can later be given access to the creds.

It might be possible that someone would want the equivilant of encryption=pubkey instead. (encryption=sharedpubkey is the same as encryption=pubkey as far as encryption of creds goes).

In future there might be some other, better encryption scheme that might be desirable to use only for creds. Eg, something other than gpg..

An alternative to support such would be to use:

encryption=<whatever> embedcreds=yes onlyencryptcreds=yes

I've made git-annex sync and also git-annex adjust error out in this situation, rather than treating it as a warning.

I also improved the error message a bit. And improved the documentation to warn against getting into this situation.

Thanks for bumping this. It was in my backlog. I've taken a look at it now.

Note that you can use the reflog to get back to the missing commits.

The git-annex-adjust warns about merging into an adjusted branch. And suggests to use git-annex merge to merge a branch into an adjusted branch. Which avoids this problem.

Probably the best thing for it to do in this situation is to fail in a way that leaves the adjusted branch as-is. The user can then address the problem, eg by resetting the adjusted branch to a point before the merge and doing the merge some other way.

It would be difficult to handle propagating a merge commit back to the original branch. Usually when on an adjusted branch, any commit of annexed files can be assumed to have the adjustment (eg unlocking) applied to the files. And so reversing the adjustment will yield the desired state (eg locked files). But a merge commit may not be of another adjusted branch, it could be a non-adjusted branch. Or it could be a branch with a different adjustment applied to it. Reversing the adjustment would then do the wrong thing.

Consider for example, if the --unlock adjustment were used. But then a branch adjusted with --hide-missing were merged in. This is basically indistingushable from merging in a branch where some unwanted annexed file is removed.

Also, it looks at the diff of changes made in a commit to know which annexed files were changed and reverse adjusts those files. In a merge commit, it's not clear which of the multiple parents it should diff against.

Hi Joey,

I agree it would make sense to have some way to embedcreds without encrypting content stored on the remote. I suppose one way to express it is as encryption=onlycreds embedcreds=yes with one or more keyids.

I am also in need of the encryption=credsonly option for the LTO tape special remote on which I am currently working.

LTO tape drives provide hardware-based AES encryption which I would like to use. However, to enable this HW-accellerated encryption, I need to initialize the tape drive with an appropriate key, which I would like to store in the annex using credentials.