9b93278e8a
The fix is to stop using w82s, which does not properly reconstitute unicode strings. Instrad, use utf8 bytestring to get the [Word8] to base64. This passes unicode through perfectly, including any invalid filesystem encoded characters. Note that toB64 / fromB64 are also used for creds and cipher embedding. It would be unfortunate if this change broke those uses. For cipher embedding, note that ciphers can contain arbitrary bytes (should really be using ByteString.Char8 there). Testing indicated it's not safe to use the new fromB64 there; I think that characters were incorrectly combined. For credpair embedding, the username or password could contain unicode. Before, that unicode would fail to round-trip through the b64. So, I guess this is not going to break any embedded creds that worked before. This bug may have affected some creds before, and if so, this change will not fix old ones, but should fix new ones at least. |
||
---|---|---|
.. | ||
Availability.hs | ||
Backend.hs | ||
BranchState.hs | ||
CleanupActions.hs | ||
Command.hs | ||
Creds.hs | ||
Crypto.hs | ||
DesktopNotify.hs | ||
Difference.hs | ||
Distribution.hs | ||
FileMatcher.hs | ||
GitConfig.hs | ||
Group.hs | ||
Key.hs | ||
KeySource.hs | ||
LockPool.hs | ||
Messages.hs | ||
MetaData.hs | ||
NumCopies.hs | ||
Option.hs | ||
Remote.hs | ||
ScheduledActivity.hs | ||
StandardGroups.hs | ||
StoreRetrieve.hs | ||
TrustLevel.hs | ||
UrlContents.hs | ||
UUID.hs | ||
View.hs |