CI to automate build of cargo lockfiles on different Alpine releases for git-annex aports
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/git-annex
3ece4758c6
Empty filenames were already filtered out as not allowed. But before the change to ByteString, a NUL could appear in an Arbitrary String, and so Arbitrary AssociatedFile sometimes generated illegal filenames, as NUL never appears in a filename. The change to ByteString meant the String was run through toRawFilePath, which assumes a filename never contains a NUL. That truncated the String at the NUL, which could result in an AssociatedFile being generated with an empty filename. The filtering of NUL added here is not really necessary, because of the truncation, but it makes explicit that NUL is not allowed. The real fix is that the suchThat now applies to the final AssociatedFile, so will catch any empty ones however generated. This raises the more general question of whether toRawFilePath might truncate other strings that later get used as filenames. I think new bugs probably won't be introduced by that. Before, a FilePath that got read from somewhere (eg an attacker) and contained a NUL would perhaps be printed out by git-annex, including the NUL, or written to disk inside a file, or what have you. But as soon as that FilePath gets passed to any IO action that treats it as a filename, it gets truncated after the NUL. Eg, writeFile "foo\NULbar" "bar" writes to file "foo". Now toRawFilePath will make the truncation happen earler, but at most this will affect what gets printed out or is written to disk inside a file; actually using the RawFilePath as a filename will not change from using the FilePath as a filename. |
||
|---|---|---|
| Annex | ||
| Assistant | ||
| Backend | ||
| Build | ||
| CmdLine | ||
| Command | ||
| Config | ||
| Database | ||
| debian | ||
| doc | ||
| Git | ||
| Limit | ||
| Logs | ||
| Messages | ||
| P2P | ||
| Remote | ||
| RemoteDaemon | ||
| standalone | ||
| static | ||
| templates | ||
| Test | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| Annex.hs | ||
| Assistant.hs | ||
| Backend.hs | ||
| bash-completion.bash | ||
| Benchmark.hs | ||
| build.bat | ||
| BuildFlags.hs | ||
| BuildInfo.hs | ||
| CHANGELOG | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| COPYRIGHT | ||
| Creds.hs | ||
| Crypto.hs | ||
| ghci | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-union-merge.hs | ||
| Git.hs | ||
| Jenkinsfile | ||
| Key.hs | ||
| Limit.hs | ||
| Logs.hs | ||
| Makefile | ||
| Messages.hs | ||
| NEWS | ||
| README | ||
| Remote.hs | ||
| Setup.hs | ||
| stack-lts-12.14.yaml | ||
| stack.yaml | ||
| Test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. For documentation, see doc/ or <https://git-annex.branchable.com/>