mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

bring back "bag of bytes" handling for ciphers

Browse source 
Fixes test suite failure with LANG=C caused by commit
3742263c99

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project
This commit is contained in:
Joey Hess 2023-11-01 13:09:42 -04:00
parent c927a38dc5
commit 9862d64bf9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 54 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_2_52185ae4ebdfcb61840444e3ef1e0404._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2023-11-01T16:53:48Z"
content="""
Will probably need to revert the Remote/Helper/Encryptable.hs part of that
commit.
What is happening here is, encodeBS is failing when run on the String from
a SharedPubKeyCipher. That String comes from Utility.Gpg.genRandom and is
literally a bunch of random bytes. So it's not encoded with the filesystem
encoding. And it really ought to be a ByteString of course, but since it's
not, anything involving encoding it fails.
That's why the old code had this comment:
{- Not using Utility.Base64 because these "Strings" are really
- bags of bytes and that would convert to unicode and not round-trip
- cleanly. -}
And converted that String to a ByteString via `B.pack . s2w8`, which avoids this problem.
What an ugly thing. Really ought to be fixed to use ByteString throughout.
But for now, let's revert.
"""]]